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: Eli Zaretskii
Subject: Re: Fwd: [PATCH] different approach to --split html
Date: Wed, 8 Nov 2000 16:24:12 +0200 (IST)

On 8 Nov 2000 address@hidden wrote:

> > 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'.

You don't need to ``buy'' anything: these issues should be discussed.  
That's why I said ``probably''.

> 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

??? How will this work for references that point to other documents?  If 
the target directory is determined at the time the HTML file is 
generated, and is entirely up to the user, there's no way two different 
files generated on two different occasions will agree on the place where 
to look for the files.

Also, this would disallow generating HTML files on one machine, then 
installing them on another, or moving the files to a different place.

> 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?

What master index?  We don't have one, at least not until now.  This is 
in contrast to the Info format, where we have the DIR files, through 
which we can implement indirection.  (Actually, the lack of indirection 
in HTML is one of the pains on the way to the solution of these problems.)

> > 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?

I don't think this is a valid assumption, in general.  Imagine a system 
where some of the HTML files where produced by an old version of makeinfo 
which didn't support splitting ;-)

> 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 `!'').

Exactly!  So they should be replaced when generating a file name from a 
node name.

> But this is a minor detail, right?

Sure, but I thought you wanted your diffs to be accepted and applied, no?

> > 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?

DOS is supported until now, and I see no reason to give up on it so 
easily.  You'd be surprised to learn how many people use Texinfo on DOS.

Besides, Windows also doesn't allow those same characters in file names.

> This could be fixed using a hash, but I'd vote for dropping 8.3 until
> maybe someone sends a clean patch for it.

That's okay, but let's not introduce additional obstacles for that 
someone, by assuming that the DOS port will never run this code.  In 
particular, replacing a few more characters in file names cannot possibly 
hurt on Unix.

> > 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?

I thought that the patches you sent are supposed to do everything, 
including the index.  Are you saying that some of the changes you used to 
produce the files for the above URL were absent from the diffs you sent?

> Especially, I would like to know if I can/should drop the
> node<number>.html approach

Probably, but I'd like to hear Karl's opinion.

> or whether (or at what cost) we should support non-splitting html at 
> all.

IMHO, we certainly should support --no-split in HTML mode.



reply via email to

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