Re: groff performance and a critique of mandoc(1)'s PDF generation

(Been out of pocket for a while… the grandson’s soccer season has
begun, and it’s looking great to begin with. I think this is the best
team he’s ever had in front of him; he’s the goalie. But I digress…)

G. Branden Robinson <[email protected]> wrote:

> It might be interesting to someday add a gromarkdown(1) output driver
> for groff.  For now, I'll await expression of demand.  :)

That would solve a lot of problems! If the output is solid, you could
completly ditch grohtml(1) because Markdown is a textual version of
HTML[1] (like AsciiDoc is a textual version of DocBook). If you aim for
CommonMark—or Pandoc’s Markdown, which might be the closest
implementation so far—it would potentially open groff not only
to the non-printing world (i.e. the web) but to much more. For
example, if you’re willing to set up a template, Pandoc can transform
an MS-Weird document to -ms. Right now, Pandoc treats groff formats
as a “roach hotel” — other formats come in, but they don’t come out.
If groff itself can handle the other direction, then single-sourcing
becomes a reality.[2]

So if by “expression of demand” you mean “someone is willing to do
testing and contribute patches according to his ability” I’m expressing!

— Larry

[1] The DITA Open Toolkit (a/k/a DITA-OT) has a Markdown output,
and can uplift Markdown into DITA-XML. It can also treat topics written
in Markdown as co-equal to XML topics… now wouldn’t that be a fun
thing to do in *roff? :D

[2] Imagine being able to pull an MS-Weird doc into Markdown,
splitting it into topics for a website and producing a nicely-typeset PDF.
A gromarkdown(1) post-processor would make that possible.