bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: [PATCH] different approach to --split html


From: janneke
Subject: Re: Fwd: [PATCH] different approach to --split html
Date: 08 Nov 2000 13:45:30 +0100
User-agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7

Eli Zaretskii <address@hidden> writes:

> > I decided to take a quick look at a more simplistic approach: mapping
> > nodenames to filenames, simply by substituting or removing unwanted
> > characters.
> 
> This is probably what we would like to do.  However, for this approach to 
> work well, you need to solve the problem of several different documents 
> which have nodes with identical names.  A typical example is "Running" or 
> "Index", which you can find in almost every GNU manual.

Ok.  I chose to ignore this problem, because the approach taken by the
preliminary 4.0 html split code (node<number>.html) wouldn't allow for
multiple info documents in one directory anyway.

> Therefore, it will probably be necessary to put each document's parts 
> into a special directory, while leaving the file with master menu in the 
> common directory.

We could do this, but I don't really buy your `Therefore'.  In
general, I dislike this kind of magic.  Why not just use
--outfile=dir/foo.html for that, and generate all of the html in a
subdirectory, that's what I do now.  A separate script, eg
install-info-html (much like install-info) would just add a link to
the master index, that resides in the parent dir?

Anyway, either option is fairly easy to implement.

> There's also a problem with cross-references from other HTML documents: 

Yes, indeed.  Would it be ok to assume that the other html documents
are split if we're split and vice versa?

> > The patch has some rough edges, eg, you can't link to anchors within
> > other nodes.
> 
> Can you explain what exactly is this limitation, and why?
> 
> > +      if (strchr (" !#$%&'", *p)
> > +     || (int)*p < 32 || (int)*p > 127)
> > +   *p = '-';
> > +      else if (strchr ("()", *p))
> > +   memmove (p, p+1, strlen (p));

For `&' and `?/' (missed those two): these can't be in plain urls.
For the others: I don't like them in file names, while they'd be ok
for node names (esp ` ' and `!'').

But this is a minor detail, right?

Removing `()' gives automatic linking to top node of external
documents, but this is broken, we should check for that and possibly
substitute the part between () to a subdirectory, and the following
node name to a file.  This should be fairly easy, I guess.

> The list of the characters we want to replace should be longer.  For 
> example, DOS/Windows systems don't allow qoutes and wildcard and

You would really like to support DOS?  I mean, this approach won't
work for DOS, in general, node-names are longer than 8 characters.
This could be fixed using a hash, but I'd vote for dropping 8.3 until
maybe someone sends a clean patch for it.

> redirection characters in file names, so "\"*?<|>" should also be 
> replaced.  Slashes and backslashes should also be replaced, otherwise you 
> will have grave problems.
> 
> In fact, I'd suggest to leave alone only the Posix characters 
> [-0-9a-zA-Z_.] and replace all the others.

Ok, I'll do that.

> Btw, how does the index work with the split files?  I didn't see anything 
> in your patches that would handle this; did I miss something?

It's all real simple, I only link to nodes, and nodes map directly to
a html file name, see:

     
http://appel.lilypond.org/lilypond/links/lilypond-1.3.104/Documentation/user/out-www/Index.html

Or maybe I missed something?  This was just a quick patch to:

   * see if it would work
   * get the Texinfo developer's input on whether or how to proceed

Especially, I would like to know if I can/should drop the
node<number>.html approach, or whether (or at what cost) we should
support non-splitting html at all.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]