groff
[Top][All Lists]
Advanced

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

Re: [Groff] ideas for splitting -Thtml output


From: Dorai Sitaram
Subject: Re: [Groff] ideas for splitting -Thtml output
Date: Thu, 26 Jun 2003 11:31:53 -0400 (EDT)

Gaius Mulley wrote
> 
> 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...
> 
> there could also be a command line option which -P-j (say)
> which can override JOBNAME or allows users to omit JOBNAME.

Yes, that would be a great choice.

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

BTW, I realized after I mailed that the .REF
macro may not be needed.  A .URL that points to
an internal anchor will always start with #, so that
information should be enough to determine that this
particular reference should be qualified with an output
html filename.

> 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.
 
Thank you very much for considering these changes.    

--d

reply via email to

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