Follow-up Comment #1, bug #68651 (group groff): To elaborate on stage 5, as it's not yet its own ticket...
I nurse a hope that adding internal "end-paragraph" macros, which would be
called at any "paragraph reset" (the traditional idiom) anyway, and also
wherever relatively unusual things like new sections, changes to columnation,
or the end of the document, occur, _might_ get most of the work done for me.
The nice thing about the full-service macro packages is that they much more
closely resemble block-structured documents already, a strong distinction from
a *roff's stream-oriented nature. I suspect this is due to human convenience
when conceptualizing and/or organizing a narrative.
There is a reason Joyce's "stream of consciousness" narrative in _Ulysses_ was
considered highly radical (and is still unusual in literature). While a *roff
formatter might think like Molly Bloom, macro packages tend to conform to the
more conventional thought patterns of a Stephen Dedalus.
There is a potential hazard with users' macro-package-using documents
rendering more horribly as HTML than with other output formats, if they resort
to raw formatter requests in ways that conflict with the "hints" emitted by
the package's internal documents. I think our remedy will likely have to be
reinforcement of truly ancient *roff wisdom that's been recognized since the
1970s. There's a trope in old *roff macro package documentation about which
formatter requests "can be used with impunity" (after package initialization).
The list is usually short. If _grohtml_ output breaks "even harder" (than
PostScript, say) because a document author didn't honor documented
proscriptions against low-level requests, I may have to play the "dick
maintainer" card and say "you broke it, you get to keep both pieces--use the
macros you've been given!".
It's also possible that we'll have to trim lists of requests "usable with
impunity" to make them even more conservative. I don't know yet. _man_(7)
and _mdoc_(7)'s lists are already empty, and have been for years.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68651>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
