Re: [Groff] ideas for splitting -Thtml output

[Gaius Mulley]

address@hidden (Dorai Sitaram) writes:

> Two things should be taken care for multiple-file
> output:
> 
> 1.  We need to know what to name these files.  
> Since groff could take its input from stdin, there may
> not be a canonical file name we can associate with the
> input.  I suggest www.tmac supply a macro called
> .JOBNAME that will allow the user to identify what the
> basename of the intended output file should be.  (The
> name .JOBNAME was only chosen in analogy to TeX's
> \jobname,  you can use a better name.)  Output files
> can be <jobname>.html followed by auxiliary files 
> <jobname-Z-H-<num>>.html, where <num> is 1, 2, 3 ...
> (Again I'm using my TeX2page convention, but it can 
> be changed.)
> 
> If .JOBNAME is not specified, there will be only one
> output file, as now.

there could also be a command line option which -P-j (say)
which can override JOBNAME or allows users to omit JOBNAME.

> 
> 2.  Any references to anchors in the groff input need
> to be qualified with the name of the output file they
> occur in.  This includes the <a name>'s used for
> section-headings and referred to in the ToC.  It also
> includes the anchors introduced by the .TAG macro.
> 
> .URL will continue to work for external links, but if
> it refers to something internal, i.e., an anchor
> specified by a .TAG, it may fail, because we need the
> particular output HTML file the anchor is in.  We can
> therefore have a www.tmac macro called .REF that is
> specifically to refer to such internal anchors.

yes this would work.
 
> Changes to the HTML generator will essentially comprise
> using the information from .JOBNAME to generate
> the multiple output HTML files, and to keep track of
> which output files each .TAG argument should go in.
> 
> Automatic HTML-page-breaking can occur as now at the
> user-specified .NH and .SH level.  In addition there
> can be an .HTMLEJECT macro that the user can use to
> force an HTML page break at that point.
> 
> I'd appreciate any input on whether adding these
> features to the -Thtml generator is feasible.  
> Making sure that the <a href> pointing to an internal
> TAG can include the correct output HTML filename
> requires looking at the input twice, but it appears
> that -Thtml is looking at the input document twice
> anyway (for PostScript inclusion).

yes adding these features is definitely feasible, there is no problem
in scanning the ditroff output a number of times as grohtml stores the
whole lot in memory before processing it.

The file splitting code shouldn't be too complex either as
all device drivers have a neat output file mechanism.

Gaius