On Mon, Sep 28, 2020, Steve Izma wrote: > I think Larry's point here is that it's not that hard to write a > script to go from a markup language to groff.
I think the crux of the matter is going from a markup language *to a specific groff macroset*, not merely "to groff." A couple of years ago, Yves Cloutier and I discussed his idea of creating an entirely new markup language, which would begin life as a markup=>groff converter and proceed from there. Needless to say, he discovered quickly that his converter needed a macroset to map the markup to; conversion to low-level groff is futile because many of the operations groff is expected to perform demand being managed by macros. Going the reverse direction, groff=>markup language (e.g. HTML), it is equally evident that only conversions from a known macroset are going to produce semantically clean results. Thus, I feel that any work done on a grohtml-like device must start by determining an appropriate macroset to use for the conversion, then extending it to include additional macrosets. grohtml(1) makes no mention of macrosets, which lacuna can only be construed by users in one of two ways: grohtml is macro-agnostic, thus it will convert any macroset, or grohtml only converts low-level groff ("...converts the output of GNU troff to html."). I believe neither is true. Using -ms as an example, I would dearly love to see the DESCRIPTION in grohtml(1) begin: "The grohtml front end...translates the output of documents formatted with the groff_ms(1) macros to html. Users should always invoke grohtml via the groff command with the -Thtml and -ms options." -- Peter Schaffter http://www.schaffter.ca