Re: [Groff] HTML fonts

[Werner LEMBERG]

> > IMHO, HTML shouldn't use fonts at all.  It should use entities only,
> > interspersed with markups.  All glyphs available in `S' should *only*
> > be accessed via groff names and not directly with the char code --
> > otherwise it would fail on other output devices anyway.
> 
> hopefully this is what is happening when eqn is run ie:
> 
> ...
> 
> eqn -Thtml eqn2.n | troff -Thtml -ms
> 
> generates:
> 
> ...
> Csr
> Cradicalex
> 
> ^^^^^^^^^^

You can access both characters with troff directly: \[radicalex] and
\(sr, so eqn does the right thing.  Of course, radicalex is defined
for devps only (-Tdvi doesn't need this character at all).

It might be a good idea to collect all available glyph names defined
for all devices in a single list for reference, specifying also
whether a given device can emulate it (e.g. radicalex).

> > As a consequence, `fonts' in devhtml should look similar to the
> > font descriptions in devutf8, i.e., all available entities should
> > be collected in a single R.proto file.
> 
> I think this is very elegant. Will it still cope with equations
> and the special character set?

Why should it?  I suggest that everything not representable with HTML
entities or macros will be handled by grops.

> > It makes no sense to mimic PS behavior for HTML output, I believe.
> 
> I like the sound of this - but I'm slightly apprehensive about what
> will happen to png images.

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.

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.

> x X html:graphic-start
> some picture
> x X html:graphic-end
> 
> to generate the picture it generates a troff output file which is
> given to grops.  It does this by scaling the html glyph positions up
> by the postscript resolution/html resolution and faking a troff -Tps
> generated equation.  I hear people stomachs turning as I write this
> :-).  If roman chars/courier chars are given the same width there
> might be a mess :-)

I must admit that I also have a bad feeling...

> It could be I'm missing something here and you've got hold of a
> elegant solution which means we can delete lines of code and remove
> duplicated dev files.  I like removing code...  especially if the
> solution is better...

Well, my suggested solution above is probably simpler (at least
cleaner) but more time-consuming.


    Werner