Hi Daniel, At 2024-08-12T20:56:30-0300, Daniel Brigante wrote: > I've been trying to make grohtml produce <sub> and <sup> html tags > from an ms input without much success. From my current understanding, > the grohtml device driver should detect both a vertical position > change and a font size change from the device independent file (as it > is described in the start_superscript/start_subscript function in the > post-html.cpp file), that would cause the driver to emmit the <sub> or > <sup> tag.
It's possible this feature is buggy or incomplete.
> When I try to force this behaviour with \v and \s calls in my ms file,
> I get the expected behaviour if I set the output device to ps, but
> when I set it to html I only get a <small> tag generated by the device
> driver. I also noticed that the "V" instructions, in the device
> independent file (using -Thtml and -Z options with groff) get removed
> by (probably, I think, the html preprocessor), only remaining the s
> instruction.
I don't have much useful advice here. I suspect, but cannot prove, that
it's simply not possible to produce high-quality HTML by instrumenting
the formatter with a state machine, which is the approach that was
taken. It's a bold claim, I know, and Werner Lemberg and Gaius Mulley
are capable developers, but grohtml never really got out of beta state--
it kind of halted in its tracks about 20 years ago--and I am tempted to
blame insurmountable design challenges for that.
What I would do is attack the problem at the macro package level. Since
macros (or strings, as in ms's case) are often used to render super- and
subscripts, these could inject device control commands to give a hint to
the output driver what was going on.
For example, groff ms, defines strings like this.
.\" superscript
.ds par@sup-start \v'-.9m\s'\En[.s]*7u/10u'+.7m'
.als { par@sup-start
.ds par@sup-end \v'-.7m\s0+.9m'
.als } par@sup-end
.\" subscript
.ds par@sub-start \v'+.3m\s'\En[.s]*7u/10u'-.1m'
.als < par@sub-start
.ds par@sub-end \v'+.1m\s0-.3m'
.als > par@sub-end
It could just as well do this:
.ds par@sup-start \X'html: <sup>'\v'-.9m\s'\En[.s]*7u/10u'+.7m'
.ds par@sup-end \v'-.7m\s0+.9m'\X'html: </sup>'
.ds par@sub-start \X'html: <sub>'\v'+.3m\s'\En[.s]*7u/10u'-.1m'
.ds par@sub-end \v'+.1m\s0-.3m'\X'html: </sub>'
...which, with appropriate recognizers in post-grohtml, would, I think,
make it hard for the output driver to guess wrong.
There _is_ already a function in post-grohtml that attempts to recognize
super- and subscripts from context without the assistance of such tags.
But, if your experience is any indication, it's not reliable.
https://git.savannah.gnu.org/cgit/groff.git/tree/src/devices/grohtml/post-html.cpp?h=1.23.0#n4074
See particularly line 4099.
My speculation, based solely on my imagination and a degree of
familiarity with the code base rather than insight into Werner and
Gaius's plans (beyond what can be gleaned from their whitepaper[1]) is
that it was thought that the tedium of hacking up macro packages to
inject "higher-level" markup into the device-independent output to clue
in an HTML generator would not be necessary if only good enough
heuristics were written into GNU troff (the formatter) and grohtml (the
output driver).
That might be be true--but it would seem we never got heuristics that
were good enough. Rendering tables, equations, and pic(1) diagrams as
PostScript and including them as raster images has proven particularly
painful.[2]
https://savannah.gnu.org/bugs/?60052
https://savannah.gnu.org/bugs/?62890
Furthermore, the level of demand for HTML production from "raw" groff
language input seems staggeringly low. It doesn't seem that anyone
exists who wants to compose groff to produce HTML without availing
themselves of a macro package, and even if they don't want to use the
macro packages we ship, they can absolutely write their own macros to
do the sort of thing I spitballed above.
I don't mean to criticize, but in my opinion groff's unspectacular HTML
production story has led to some losses. If it had been less ambitious
and focused on rendering man pages well as an initial goal, many ad hoc
grotty output scrapers would never have been written to produce HTML,
and mandoc(1) might not ever have happened.
Again, just my opinion--I wasn't there at the time. Werner and/or Gaius
may very well have strong counterarguments that I simply haven't heard.
So if they weigh in, listen to them.
In any case I won't be tackling "groff html-ng" in the near future. I'm
trying to finish feature changes to the formatter for 1.24 so it can
freeze, and, I hope, be released this calendar year.
Regards,
Branden
[1] https://www.gnu.org/software/groff/grohtml.pdf
[2] GNU eqn can already produce MathML. It could use some automated
tests.
signature.asc
Description: PGP signature
