Re: (off topic?) Docbook? Re: manlint?

[James K. Lowden]

On Thu, 8 Oct 2020 02:38:04 +0200
Ingo Schwarze <schwarze@usta.de> wrote:

>  * texinfo2mdoc(1) is by far the most experimental of the three.
>    It has never been used in production.  Feeded real-world documents,
>    i would expect that it probably mishandles part of the input.

Noted, and thanks.  If I go down this road, I'll try to provide
useful feedback.  

> Right now, i wonder whether maybe your mindset in this context was to
> (mostly?) regard roff as a HTML generator.  

I can see how it might seem that way.  I use groff mostly for mdoc and
ms.  I usually view mdoc through nroff and ms as PDF.  

I recently revised the texinfo sources to produce
https://gnucobol.cobolworx.com/.  I would have preferred to work in
mdoc and am considering the feasibility of converting to it.  As you
might expect, "feasibility" is not just a technical matter.  Good HTML
in addition to PDF would, hopefully, mean less cajoling. 

>   .SH Id foo Class bar
> 
> But even then, i don't particularly like the idea of designing
> syntax with one specific output format in mind.

I share your conservatism.  I just don't see a better alternative.  

I think it's accurate to say -ms achieves device independence
only by not exploiting any device-specific features.  

We already do have device-specific syntax in the form of \X, \Y,
and .device. We already have device-specific macros, too.  To write PDFs
with hyperlink support requires pdfmark macros.  To write HTML with
hyperlink support (in groff) requires www macros.  

Why is there no .LK macro for device-independent hyperlinks? (You're a
good person to ask.  Whatever happened to your .Lk for mdoc?) 

HTML and PDF are the only two output devices that matter anymore.
They've been around for decades and show no sign of disappearing.  They
both have features that didn't exist when -ms was designed. 

No printer has a "section heading" feature, much less one with varying
sizes and styles.  How else to convey that information to the device,
if not by allowing the author to express them?  If he is going to
express them, why restrict him to device escapes?  Why not extend the
macro syntax (which is easier to type and read) and document that
certain attributes affect only HTML?  

Another example is forms.  Both PDF and HTML support forms that the
user can fill in. In a Postscript file, forms are just white space and
lines.   Interactive forms, though, are explicitly defined in a PDF or
HTML document, including their tab-stop order.  

ISTM we either mothball -ms and consign it to printers, or adapt it and
make in more useful to present circumstances.  

--jkl