Re: [Groff] Back to the future

[Eric S. Raymond]

Peter Schaffter <address@hidden>:
> It isn't groff's place to produce presentationally-neutral output, but
> rather to receive presentationally-neutral output and interpret
> it for typesetting.  The logical flow isn't groff => XSL-FO, it's
> XSL-FO => groff.

Agreed.  This sounds like you and I are coming to the same place from opposite
directions - that is, groff and its quasi-semantic markups need to be prised
apart so the markups can become more semantic.  They can't be separated 
entirely, but some serious narrowing of interfaces is required.

> Corollary to acknowledging that groff's primary role is as a
> typesetting backend is keeping debates about manpages, semantically
> useful macros, and well-formed input files distinct from discussions
> about code development.  What goes on in macroland should stay
> in macroland.

Again, I agree.  Thus my hygiene proposal; that's how we keep the 
macroland abstractions from being violated (when it's a good idea
to enforce that, which is admittedly not always).

>                Whether, or how, well-formed files and macrosets
> should/could be xml/stylesheet-parsable in a semantic world has no
> bearing on groff's future.  It's a front-end debate when back-end
> development is what's needed.

But this I disagree with on multiple counts.

Firstly, front end and back end issues are *not* orthogonal, because
nobody is ever going to design groff macros in a way that is totally
decoupled from the capabilities of groff's back end. (And even
intending to do that would be silly.)

Secondly, I think you can maintain this position only by taking an
ahistorically narrow view of what 'groff' now is.  Like it or not, we
remain responsible for supporting some important non-typesetting
use cases - notably, man pages browsed through terminal emulators.

We can't simply abandon that job; it follows that we need to think about
how to do it better, and - if you really want groff to narrow its scope
to be a typesetting back end only - we need to think about how to hand
off that job and what to hand it to. 

Fortunately for your vision, that is *precisely* what *I* have been doing...

>           The manpages debate is largely about groff usage, not
> groff development.

No. In the terms of argument you yourself have chosen, it's a debate
about the design philosophy of front-end macros.  You are free to try
to pretend that this is not an aspect of groff development if you like,
but I am quite certain the rest of the world will not accommodate you in 
this.

> One shouldn't have to be a geek to benefit from the advantages,
> which leads me to think that, ancillary to backend improvement,
> there's a pressing need for groff advocacy.  Put another way, folks
> need to know that using groff to format a novel isn't novel.  It's
> pretty routine, and you shouldn't have to be a hacker to do it.

Me, I think this is a doomed enterprise. For this use case the rest of
the world has moved on to DocBook, wiki-style markups, markdown, and
asciidoc (that is, if they're not using a WP to begin with).  I can't
see any reason at all it should look back.

If you want to preserve a role for groff, you need to start by being
realistic about the range of use cases it's fit for in 2014 and going
forwards.  Formatting of the general run of novels by casual users is
not among then; that's *gone*, already lost to tools that play better
with ePub.

"Dedicated back end for high-quality typesetting", on the other hand,
is realistic.  It's a niche, and probably a shrinking one - but if you
hew to that, groff may prosper.

> If groff's formatting engine, the backend, were to be brought
> up to snuff with TeX's, then the answer to my question would be
> even easier: we need both groff and TeX because diversity fosters
> evolution.

That, too, seems a reasonable goal.

> Why do I care?  Well, with the greatest of respect to Eric, I
> feel that "the page", as it has been recognized for centuries,
> is far, far from being irrelevant to the future of material
> intended to be read at the screen.

I think we'll just have to disagree on this.  You sound to me like
a Babylonian scribe arguing that reading won't be *right* without
the feel of the clay tablet in the reader's hands.

Fortunately, we can disagree on this and still cooperate.  The things
I am interested from are separable from the things you are interested
in.

> To that end, I propose, as someone else did (sorry, can't seem to
> find the post quickly), that we draft a sort of mission statement or
> set of guidelines.  Chief on my list would be:
> 
> 1.  Backward compatibility remains a top-level priority; not
>     exactly sacrosanct, but very close to it.  Mike still needs
>     those 70s documents. :)
> 
> 2.  Primary development geared toward overhauling and updating the
>     backend, both its approach to formatting and the requests that
>     drive it.
> 
> 3.  No changes to the syntax of existing requests.
> 
> 4.  Where existing requests would benefit from being made more sane
>     for the purposes of macro writing *in the future*, either add a
>     compatibility flag or create new requests in a vein similar to
>     de1, am1, etc.
> 
> 5.  Implement new requests freely (as, for example, when Werner
>     added .fzoom) provided they do not break backward compatibility.

These are reasonable.  I would add:

4. Identify 'semantic' macro packages, including man markup and possibly mom.
Work towards systematically isolating those macro sets from groff-specific 
back end details, with the general direction of making them more semantic
and enabling simpler non-groff rendering engines for terminal and web use.

5. Improve the semantic expressiveness of man markup.

I'm willing to work on these things, not just talk about them.  To be
more concrete, I'm willing to own the cluster of design and implementation 
problems around man macros.  

> If others on the list are prepared to make--and debate--"big
> picture" suggestions for a statement of this sort, I will see to
> the compiling and writing of it.

All hail the new project leader! :-)

> As before, apologies for the long post.  In future, if members would
> prefer, I can post to my blog and send links to the list instead.

I think this is the right place for the conversation.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>