>>>>> "EZ" == Eli Zaretskii <[EMAIL PROTECTED]> writes:
EZ> It's not trivial. In order to work, there's a need for a
EZ> universal agreement with whatever standard we adopt, and that's
EZ> not easy, considering texi2html and whatever tools are out there.
I don't see why. (rms told me to ignore texi2html as far as I
remember.)
EZ> Not off the top of my head, no. I just remember several annoying
EZ> complications, on top of makeinfo's already not-so-clean
EZ> architecture, to say the least.
You can say that again! It's one reason I wanted to generate
intermediate SGML and process that.
EZ> Previously, @contents was working correctly only if it was near
EZ> the end (except in TeX). Now you can put @contents anywhere in
EZ> the document. This required to add a second pass.
I guess I worked on a version with that in.
EZ> Sorry, I don't understand what do you mean by link
EZ> meta-information.
The <link> elements record the Texinfo structure and allow a `user
agent' to navigate without reading the text. Without that you can't
use the HTML as a decent replacement for info, particularly for things
like finding and processing indexes. (Currently you can probably only
use the information in W3 with a bit more hacking, but probably you
could provide such features in other browsers using ECMAscript or Java
-- I don't know. I intended to finish the features in W3 as Bill
Perry always intended when there was a canonical tool generating the
markup.)
EZ> The names themselves were not that bad (except for the 8+3 DOS
EZ> names, but that could be solved).
I think imposing such a limit here would be unreasonable -- it would
mean you couldn't do the job properly as far as I can see.
EZ> The problem was how do you compute a reference to another HTML
EZ> file that was also split: you don't know the name of the specific
EZ> sub-file where the referenced node lives in the other document,
You do if you assume that the other file was generated with the same
conventions, which seems both reasonable and necessary to me.
EZ> and HTML files lack tag tables that remove this problem in Info.
With a convention for processing <link> and/or <meta> information, you
could provide that, but I don't see why you need it if URLs reflect
node names.
