bug-texinfo
[Top][All Lists]
Advanced

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

Re: Texinfo -> HTML issues


From: Aubrey Jaffer
Subject: Re: Texinfo -> HTML issues
Date: Wed, 28 Jul 2004 21:45:49 -0400 (EDT)

 | Date: Wed, 28 Jul 2004 12:31:54 +0300
 | From: Alper Ersoy <address@hidden>

 | Suppose we are using makeinfo --html --no-split texinfo.txi and make
 | the output available online.  The output document would be
 | texinfo.html.  When the document grows, we may decide to split the
 | output into chunks, and then the output goes to a texinfo.html/
 | directory.  In this case, existing links (especially off-site) will go
 | on working.

I am unfamiliar with this modality.  If I have the link
HREF="../slib.html#current-time" and a directory slib.html, how is
#current-time dispatched to the correct file?

 | > Recoding every "-" as _002d is hideous; and totally unnecessary on a
 | > file-system supporting spaces or "-" in filenames.  Please make this
 | > recoding an option to makeinfo.
 | 
 | But there's a very good reason we are making things this way: to make
 | the nodenames predictable, and unique as much as possible.

I think makeinfo has emphasized uniqueness too much.  If makeinfo put
spaces into filenames and didn't escape "-", I could live with the
encoding.

 | If I want to link to a node in an external document, makeinfo will
 | be able to pinpoint the exact chunk in the pile.  If makeinfo puts
 | more than one node in the same file (due to nodename to filename
 | conversion deficiencies), and you want to link to one of them from
 | some else document, how will the user understand which one you are
 | referring to?

Multi-node HTML files have too many problems, and I have explicitly
advocated against them.  I would deal with it by always producing one
HTML-file per node.

 | >  | > * makeinfo HTML pages don't pass validator.w3.org because they lack a
 | >  | >   DTD.  Why isn't one generated?
 | >  | 
 | >  | I was told older versions of some browsers had problems with DTD
 | >  | lines.  Otherwise I would already have added one.
 | 
 | > How many years will makeinfo continue to produce nonconforming HTML in
 | > support of this rumored browser bug?  Maybe it could be a flag, say
 | > @nohtmldtd
 | 
 | Documents are valid, even if they fail due to the missing document
 | type declaration.

That is not true; the DTD is required for HTML 3.2.

  From the HTML 3.2 Reference Specification:

  The Structure of HTML documents

  HTML 3.2 Documents start with a <!DOCTYPE> declaration followed by an
  HTML element containing a HEAD and then a BODY element:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
    <HTML>
    <HEAD>
    <TITLE>A study of population dynamics</TITLE>
    ... other head elements
    </HEAD>
    <BODY>
    ... document body
    </BODY>
    </HTML>

 | > Here are function definitions for "distribute/" as produced by
 | > makeinfo --html 4.7 and texi2html 1.52 circa 1998:
 | 
 | [examples snipped]
 | 
 | > They produce similar output; but the lower one is HTML-3.2 conforming
 | > while the top one is not (class is not an argument to div).  HTML-3.2
 | > is very widely supported and can produce fine manuals.
 | 
 | But we have to match the looks of Info and DVI outputs in HTML.  We
 | get complaints when makeinfo fails to provide this similarity.

Then there must be something wrong with how I have texinfo-4.7
installed.  The Info and HTML files have "-- Function:" on the left;
while the DVI file has no dash and "Function" is to the right.

HTML-3.2 is capable of producing either look.

 | > Using HTML-4 when its extra features are not required needlessly
 | > breaks rendering on older browsers.
 | 
 | We allow custom CSS to be attached to files, so we have to classify
 | document divisions to allow authors to stylize specific portions.
 | Therefore we _need_ class attributes.

CSS is not required to "match the looks of Info and DVI outputs".
HTML-4 and CSS are enhancements.  The output format should be under
control of a command-line flag.

 | >   @xref{Time, current-time, , slib, SLIB}
 | 
 | > currently translates to:
 | 
 | >   See <a href="../slib/Time.html#Time">current-time (SLIB)</a>.
 | 
 | > I would have it be:
 | 
 | >   See <a href="../slib/Time.html#current-time">current-time (SLIB)</a>.
 | 
 | You are referring to the Time node of SLIB document, right?  In
 | that case, the output is correct, and it points to the start of the
 | node.

It is referring to the current-time definition in the Time node.




reply via email to

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