Re: [Groff] Back to the future

[Ted Harding]

[For response, see at end]
On 03-Mar-2014 21:43:27 Peter Schaffter wrote:
> I thought I'd leave Future Redux alone for a while to see where
> the cards fell.
> 
> List members, apparently, suffer somewhat from ADD because--no
> real surprise--it forked into a discussion about manpages.
> I've no quibble with that, but if we're to figure out what to do
> about groff in the future, we're going to have to stick to the
> big picture. Discussions about presentational vs semantic, manpages
> vs info, terminal vs browser, etc are muddying the waters.  If I may
> mix metaphors, it's preventing us from seeing the forest for the trees.
> 
> I propose applying not so much Occam's Razor as Occam's Hatchet for
> the time being.  As Eric realised in his bacon-and-eggs epiphany, a
> lot of this stuff is red herring, and it's causing us not to think
> clearly.
> 
> That said, and only because it makes my point, I'd like to report my
> own bacon-and-eggs (cornbread-and-cappuccino, actually) epiphany:
> we've been looking at the whole xml/semantic issue backwards.
> The logical flow isn't groff => XSL-FO, it's
> XSL-FO => groff.
> 
> In the simplest of terms, groff is a typesetting backend.
> 
>   Deri James:
>     "I use groff as a typesetting engine called from a front end...all
>      I want is a fast engine which handles the typography."
> 
>   Tethys:
>     "I too use groff as a typesetting back end."
>    
>   Chad Roseburg:
>     "This is the primary use case for us as well [ typesetting backend]"
> 
>   Ingo Schwarze:
>     "...groff is really the tool for producing quality typeset output
>      even of manuals."
> 
> We have a bit of a terminology problem in that typesetting, which
> used to mean *setting* type, increasing means *rendering* type.  Thus,
> to speak of groff as a typesetting engine is a tad confusing,
> since, more accurately, it renders type, primarily for two modes of
> presentation: terminal and PostScript/PDF.
> 
> It does a good job, too.  And it's been doing it for decades
> "with with considerable grace under fire." [cstr54, 2nd ed.]
> I see no reason why it shouldn't continue to do so in the future.
> It's proven itself flexible enough to accommodate a whole whack of
> changes without ever losing touch with its origins.  It's a mighty
> accomplishment, and one not ready to be declared moribund.
> 
> 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.  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.
> 
> I use the term front-end for macros because that's what they,
> whether user-written or from a distributed set.  It's how we all see
> them; it's how we all use them.  When I started work on mom, that
> was my goal: to create a macro set that formed a complete front end
> to groff, analogous to LaTeX.
> 
> I field enquiries about mom off list, and I notice that users
> tend to view mom as an application in and of itself, with groff
> merely taking care of the final typesetting.  I posit that since
> groff is perceived and used this way, its future rests on how
> well it performs as a typesetting back end.  All other concerns
> are secondary, including groff's role as a Unix documentation
> formatter.  The manpages debate is largely about groff usage, not
> groff development.  (I much to say about manpages, but shall forgo
> it here in order to follow my own advice.)
> 
> A frequent comment I see is: "And here I thought groff was just
> for formatting manpages."  To be honest, way back when, I might
> have thought the same thing were it not for happening upon the
> cstr54 when I was researching typesetting with GNU/Linux.
> 
> Groff has a terrible reputation outside the cognoscenti: archaic, of
> limited use, poor typesetting compared to TeX, legendarily difficult
> to master.  None of it is true--except, of course, the last bit.  (A
> joke-list that circulated for a while entitled _The Ultimate Geek_
> had as one of its items, "Writes own groff macros.")
> 
> The "old-school, for geeks only, manpage formatter" aura surrounding
> groff is unwarranted, especially after Keith and Deri made
> full-featured, direct-to-PDF a reality.  Yet it persists.  As
> recently as this past fall, Robin Haberkorn, a contributor to
> mom, made the comment, "How many prose writers are geeky enough to
> use groff?"  (Hmm...let's see...there's Alejandro, and I, and...?)
> 
> For preservation of content, ease of modification, and efficiency in
> typesetting, the batch processing model is superior to all others.
> 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.
> Mind you, that entails robust and easily-mastered front-ends--but
> where are these front-ends to come from if we don't attract new
> users who have the knowledge, drive, and skill to write them?  And why
> would this new crop of groffers come to groff at all when there's
> TeX, with its stellar reputation for typographic excellence?
> 
> In the Redux post, I asked the question: Do we need groff at all
> when there's TeX?  That no one took the bait means either that no
> one can answer the question, or that the answer is self-evident.
> For me, it's the latter.  Groff is leaner, meaner, and faster.  Its
> programming syntax is beyond simple.  Its request set is extensive
> and supplies users and macro programmers with an addictively good
> typographical Meccano set.  With groff, if I can dream it, I can
> build it.  As Clarke Echols says: "groff has incredible flexibility
> for the imaginative, even far away from typography."
> 
> 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.  For example, Steffen Nurpmes observed:
> 
>   "...when i look at TeX output once in a while, i indeed feel
>    uncomfortable, especially when i look from a bit of a distance: This
>    appearance of «painted uniformity» all over the paper..."
> 
> I'm glad someone else has noticed this.  It's like the Gutenberg
> Bible: the grey is so uniform I'm more inclined to admire the
> typography than read the words.  Which indicates that TeX is not yet
> the _ne plus ultra_ of Unix typography since it does not evince a
> satisfactory page rhythm to go along with its excellent _gris_.
> 
> (I do wish "page rhythm" weren't to typography what "swing" is to
> music: impossible to quantify, undeniable when it's present.)
> 
> I'm not suggesting this should be groff's goal, rather that
> there's room for improvement in both TeX and groff when it comes
> to typesetting.  Groff's backend could benefit enormously by
> adopting/adapting elements of the TeX approach, but who's to say
> that TeX could not benefit equally from developments within groff?
> It's a cross-pollination that won't happen if groff stays stuck
> where it is.
> 
> 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.  The rectangular, portrait
> orientation of the majority of printed material since Gutenberg
> isn't an accident.  The host of psychological and cognitive factors
> responsible for its overwhelming adoption won't go away simply
> because browsers hugely favour landscape orientation with natively
> long line-lengths and an absence of fixed, proportionally-balanced
> whitespace framing the text.  Eric's reservations about PDF and
> linking aside, given a choice between "Read HTML" and "Download
> PDF", I will always select PDF because the content is more easily
> grasped when the typography adheres to the printed-page paradigm.
> If we abandon the paradigm, if we dispense with it because black
> squiggles on dead trees just ain't the way of the future, we become
> victims--short-sighted victims--of fashion and expedience.
> 
> I realize all this blather is useless if groff doesn't have a
> technical lead, or leads.  Had I Eric's "wizardly coding chops", I'd
> begin exploring ways to implement what I've discussed here myself,
> very likely by studying Gunnar Ritter's work (Heirloom Troff) and
> folding it into groff.  I do not, however, have said chops, not by a
> country mile.  (I can't even get ssh and git to cooperate so I can
> clone the repo, despite 12 years of error-free ssh/cvs-ing to and
> from Savannah.)  Which is by way of saying that the most pressing
> need for groff right now is a technical lead, and whatever we can do
> to attract one--preferably one with Werner's sensitivity to the big
> picture--is our first priority.
> 
> 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.
> 
> 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.  I stress "big picture" because,
> while we all have our pet peeves and favourite soapboxes, we need to
> figure out where we want groff to go before we can address them.
> 
> 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.
> 
> -- 
> Peter Schaffter
> http://www.schaffter.ca

Thanks for this "long post", Peter! I had decided to keep out of this
discussion so far, for much the same reasons as Peter discusses at
the start of his post --  indeed, essentially because, extending
Peter's metaphor ("I propose applying not so much Occam's Razor as
Occam's Hatchet for the time being"), the discussion risked becoming,
and indeed became, Occam's Beard! Which, for those wondering what
that might be like, grows haphazardly with long and vigorous tufts
emerging overnight in unpredictable directions. And, à propos, I
attach a little document I recently composed (using groff of course)
as a PS file: buffon_needle.ps
(written for some mathematical friends with whom I was discussing
the "Buffon Needle" problem). Anyone feel like re-creating this
using TeX?

To focus now more closely on the main point. I am, I think, fully
in agreement with Peter's view on groff/troff. In summary: It is for
making marks on pages -- it can place any mark you please in any
position on the page that you please; and this can for the most part
be done fairly simply (though some instances require intricate and
fairly cleverly composed mark-up). It is indeed a page-composing
"back-end".

I write many technical (as well as quite a few non-technical) documents,
usually requiring mathematics and often needing carefully composed
diagrams or figures. The design of the layout of all such components
is crucial, in order to present something to the reader in which the
reader will directly perceive the information I want to communicate,
and share the impression that I have of the subject-matter.

Groff, as it stands, is very good at this (though there are some details
of its implementation which could be helpfully changed -- one such
being that one should be able to do real-number arithmetic throughout,
instead, as one is in many contexts, of being restricted to integer
arithmetic).

TeX, however, I am less happy with. For one thing, it is cumbersome.
For another, its notions of mathematical composition (for which it
was indeed expressly designed) do not usually please me aesthetically.

There will continue to be a rôle for "printed page" documents: either
printed onto paper (onto which, also, the reader can write notes using
a pen), or displayed on-screen using a PS or PDF viewer. As Peter says:
"Groff is a rendering engine that produces typeset copy, the same way
that a browser is a rendering engine that produces screen copy. It
isn't groff's place to produce presentationally-neutral output, but
rather to receive presentationally-neutral output and interpret it
for typesetting." To this I would add that by no means all documents
can be satisfactorily "HTML'd" -- for most of what I write myself,
the only satisfactory representation in a browser would be via a link
to a PS or PDF file. Then the reader would see what I want them to see,
and not what some "know-it-all" piece of software thinks it ought to
look like. (see [A] below)

And this is also relevant to my feelings about TeX. In groff/troff,
it is usually straightforward to "fine-tune", or "micro-adjust",
the details of the layout when one is finally preparing the final
version. I don't think this is so easy in TeX, though I may be wrong.

[A]
An example which I would not wish to be "HTML'd" is at:
  http://www.zen89632.zen.co.uk/R/EM_Aitken/em_aitken.pdf

[B]
For another nice example which groff handles very smoothly, see:
  http://www.zen89632.zen.co.uk/Misc/Bibbys_Normal_quote.pdf

[C]
And, for those interested in the ancestry (incestry?) of Cleopatra:
  http://www.zen89632.zen.co.uk/Misc/cleopatra_pedigree7A.pdf
(this one done almost inteirely using 'pic')

I could go on ... and on ... and on ...

Many thanks, Peter, for your clear an well-focussed comment!

Best wishes to all,
Ted.

-------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Date: 03-Mar-2014  Time: 23:36:10
This message was sent by XFMail
-------------------------------------------------

buffon_needle.pdf
Description: buffon_needle.pdf