Re: [Groff] new grohtml was (HTML fonts)

[Gaius Mulley]

> I have a heretic solution to the image problem: My idea is to run
> groff twice.

> The first time, groff is called with -Thtml.  An additional request in
> the DESC file should cause groff to send the whole input file
> literally to grohtml; this data is saved temporally.

maybe we could use a 'prepost` flag inside DESC

> The second time, the literally saved data is sent again to groff, but
> this time with -Tps.  grohtml can additionally modify/mark the data as
> needed.

> I see two advantages:

> .) A clear separation between HTML and other devices, especially
>    fonts.  I can e.g. imagine that a yet-to-be-written gropdf is used
>    instead of grops for various data on a HTML page.

> .) Some higher-level information in the source code could be directly
>    analyzed by grohtml which would be lost otherwise.  This will
>    improve HTML code.

so when groff -t -e -p -Thtml -ms filename.ms is invoked it generates say:

tbl filename.ms | eqn -Thtml | pic | pre-grohtml

the pre-grohtml examines input. Sees .TS, .EN, .PS and the end equivalents.
It could cut out these regions of troff input and replace with
.IMAGE  or a positional varient. It then passes the remaining troff input
to troff -Thtml | post-grohtml and the cut out bits to troff -Tps | grops.
Finally pre-grohtml converts the images into transparent png files or
pdf files. post-grohtml only handles html.

A very neat idea Werner. It would also have the advantage of solving
the bug exposed by Lester's paper and Eric Raymond's PIC guide.
[ Eqn macros and Pic macros confuse the current grohtml. ]

There shouldn't be a great deal of coding either.

Actually we might be able to do slightly better if all troff input
is passed to post-grohtml which could either use the image
file if any glyph within the pic/tbl/eqn is not known otherwise
generate straight html. But this is a minor optimization in the
grand scheme..

cheers Gaius