[Top][All Lists]
[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