[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cross manual references in html manuals
From: |
Eli Zaretskii |
Subject: |
Re: cross manual references in html manuals |
Date: |
Sat, 24 May 2003 11:36:27 +0300 |
> Date: Mon, 19 May 2003 15:58:23 +0200
> From: Dumas Patrice <address@hidden>
>
> generation of cross reference
> -----------------------------
>
> Given a node name and a manual name what remains to be found is the
> base directory and host name. I think that a recommendation could be done,
> to follow a file mapping a manual to an host/directory as Karl said. The
> location, name and format of this file should be specified as precisely as
> possible such that different application can share the same file.
> Otherwise the default host/directory could be ../ (ie parent dir on the
> localhost) as makeinfo allready does. Of course, the software may override
> this default and also what is specified in the file.
It would be a Good Thing, IMHO, if we could find a way to make HTML
browsers behave like Info readers. That is, make them search for HTML
files in some user-definable list of directories. Then the Texinfo
formatters (makeinfo etc.) would be freed from the need to consider
directories, subdirectories, and host names.
I don't know whether this pipe dream is achievable, but perhaps we
could alleviate the pain to some extent by using the same trick
"makeinfo --html" uses now for translating @anchor's: it produces an
otherwise empty HTML file which redirects the browser to another file.
Just a thought.
> The software generating the manual target of the cross reference should
> generate a file per node
Please keep in mind that it is a popular request to have an option of
splitting by chapter, not by node. I think it's a reasonable request,
and so we should not introduce changes in how HTML is generated that
would break split-by-chapter mode when it is implemented in the
future.
> In the case of multiple nodes with the same file name, the software should
> warn the user, and it is only required that the file leads to one of
> these nodes. Thus some nodes may not be attainable.
I agree with Karl that this will not be acceptable for our users.
Once again, thanks for a concise description of the issues.