Re: [Groff] Mission statement, second draft

[Steve Izma]

I am jumping in here, for which I apologize, because I have
not had enough time over the last couple of months to become
inovled in this discussion. All my spare time outside of my
regular work during this period has been spent typesetting with
groff: two newsletters, and a 200-plus-page book with over thirty
graphs (using grap), and a program for a play, all using XML as
markup and the best typesetting engine in the world (groff) for
producing the output.

> Peter Schaffter <address@hidden>:
> > 
> >  "(I have a weirdly retrotech idea that we could do typesetting with
> >    groff.  For regular prose, groff is every bit as powerful as TeX,
> >    while being about one tenth the size and complexity.)"
> > 
> > If groff is as powerful as TeX while being one tenth the size,
> > why on earth does the author dismiss it out-of-hand as weirdly
> > retrotech?  

Peter is quoting John Maxwell, who has been trying for years now
to get the publishing industry to think along the lines that
Eric has been espousing (use structured markup). John and I
have met several times to work out some methods and principles
for typesetting XML documents, and he's very familiar about my
arguments in favour of groff. His "weirdly retrotech" comment is
tongue-in-cheek, and he's essentially making the same point as
Peter.

I agree with Peter that there's something very odd about the
preference for TeX. I think it's likely just because that's what
the vast majority of math and computer science students around
the world have been told they must use in their documentation
(theses, journal articles, etc.). About ten or so years ago,
I produced about twenty books of computer science conference
proceedings with TeX and LaTeX, and I think the system is
overrated. The idea of the paragraph optimization is good,
but the practice is a pain. When TeX fails in its efforts to
justify a line, it fails spectacularly -- it oversets the line
(i.e., into the margin). (Perhaps I'm ignorant about how to turn
this "feature" off.) Trying to fix this is far more painful
than in groff, because the kerning commands are very imprecise
(e.g., "sloppypar"). The track kerning facility in groff allows
adjustments, obviously, in 1/1000th of a point. I've always been
able to fix problem paragraphs faster with groff.

Anyone concerned with quality typesetting has to scan and make
human judgements throughout the text. You can't rely on
algorithms, although obviously they can reduce problems
considerably.

But even besides this, TeX is not a filter (so it does play well
with other filters) and is very noisy. Groff is clean and agile
compared to it.

On Tue, Mar 18, 2014 at 06:13:11PM -0400, Eric S. Raymond wrote:
> Subject: Re: [Groff] Mission statement, second draft
> Here are several reasons groff gets written off as "weirdly retrotech":
> 
> * The [nt]roff markup design has a lot of tells that it was designed
> for very old machines that were ridiculously underpowered even by the
> standards of, oh, 1990, let alone today.  Line-by-line formatting,
> short request names, limited number of font positions, no color
> support, a hole where embedded image support ought to be, things like
> that.  Don't counter that groff fixed some of these things; that would
> be missing the point, which is that the core design screams "legacy!"

I don't think this is fair commentary. The command structure
(request names, etc.) is irrelevant to the underlying algorithms,
which were completely re-vamped by James Clarke circa 1989
(presumably on his Sun Workstations, hardly underpowered for
1990), with help from the intense work that SoftQuad did on the
original AT&T code in the mid-eighties. As I've said above, my
practical experience is that the line-by-line formatting does not
make a big difference. As for "legacy", what about "ls", "cat",
"grep"?

> * Sheer calendar age - a lot of people not sophisticated enough to spot
> those tells know it was written 40 years ago.

Quality typesetting requires not just good tools but lots of
experience. That hasn't changed since Gutenberg. I don't think
the idea is to create a typesetting tool that looks fashionable.
Adobe's got that market cornered.
 
> * Strange, irregular, archaic-seeming markup design compared to XML or
> even TeX.  Brian Kernignan called it "rebarbative" in *1979*.

Groff is a filter. The input language, the markup, etc., is
entirely arbitary. I've been feeding groff SGML and XML since
1988 or 1989 and SoftQuad was doing it for sqtroff long before
that.
 
> * Weak support for HTML output, no support for ePub.  People on this
> list may think it's just fine that groff is so printer-oriented, but I
> promise you nobody else who was out of diapers by 1996 shares *that*
> quaint opinion.

I have always agreed with your encouragement of creating
documents in a structured markup language. There's nothing
intrinsic to groff that prevents this. With a structured document
you go straight to HTML or ePub through scripts; groff is
irrelevant to this, except that it makes it possible to have an
XML (e.g.) document as the canonical source and then use various
filters to get the output you want. You can put everything you
need for typesetting into the XML document (even processing
instructions, if you're really desperate) and it shouldn't
interfere with the filters that don't need that information.

I realize what I've left out up to now is the issue of macros,
which makes the difference as to how the input markup is handled.
But we need to separate groff as an engine from the macro
packages built on top of it. For structured input, you need
structured macros, but that's not a big deal:

<h1>This is a subhead</h1>
<p>Lots of text.</p>

The SoftQuad people put me on to this:

.de h1((
.code ...
..
.de h1))
.ending code ...
..
.de p((
.set a first line indent & handle other stuff
..
.de p)
.br
.maybe unset some stuff
..

and so on. There are so many good examples around of the
underlying algorithms for page breaking, floats, footnotes,
multi-column setting -- none of which become obsolete just
because the document is highly structured.

        -- Steve

-- 
Steve Izma
-
Home: 35 Locust St., Kitchener N2H 1W6    p:519-745-1313
Work: Wilfrid Laurier University Press    p:519-884-0710 ext. 6125
E-mail: address@hidden or address@hidden

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
<http://en.wikipedia.org/wiki/Posting_style>