Re: [Groff] Mission statement, second draft

[Ted Harding]

I generally agree strongly with the views of Steve Izma below.
Some comments in-line; and an important question about the
"structured manpage" issue is at the end.

On 19-Mar-2014 05:11:33 Steve Izma wrote:
> 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.

I heartily agree! When TeX first emerged publicly around 1990,
I gave it a try and disliked it (also, then it was no good at
table layout -- I had colleagues using TeX who would come and
ask me to get their tables to look right: using groff!).

The one thing really going for TeX right from the start was the
comprehensive font-set including a very wide range of mathematical
symbols, which caught the fancy of the scientific community and
led to its wide adoption. Of course, the TeX fonts are available
for groff too; but I have to say that I don't really like the look
of the TeX glyphs. And getting TeX to produce a printed text that
loked as wanted it to look would, I suspect, involve enormous trouble.

And, even now, it seems TeX can get things wrong. I have seen
frecent mathematical articles in journals, typeset with TeX, with
in-line mathematics where subscripts from one line are over-printed
by superscripts from the line below. {t|g}roff would not do that
(unless you forced it to).

> 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.

Again I heartily agree! (See also below).

> 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.

Yes!!!

> 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"?

<Reminiscence>I first encountered troff around 1984 in the Softquad
version sqtroff (which our irreverent secretaries promptly renamed
"sqitroff"), running under UNIX on a machine with 1MB RAM and a 10MB
hard drive, with a 25-port serial on the back with cables running
to peoples' offices (I ended up administering this system). With a
few users simultaneously working, you would hardly notice that anyone
else was there; but once there were more than 6 or 7 then it started
to grind to a halt. Pretty good for such hardware though!

We were a Maths department, and we got it to produce example sheets,
lecture notes, and exam papers using sqtroff. It worked beautifully.
Then people started using it to write articles for publication etc.
I also produced camera-ready copy for a couple of book translations
(including diagrams with 'pic').

When groff came out (late 1980s) I was using it under DOS (Linux
not then available) and it still worked beautifully!</Reminiscence>

>> * 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.

Again heartily agreed! I'm still using wooden ploughshares pulled
by horses, but I can plough beautiful furrows in any shape I wish.
But my neighbouring farmer, who is into modern mechanical tractors
steered by SatNav, all too often ploughs up part of his fruit orchard
or his wife's flowerbeds. Of course, he doesn't think he needs to
look where he's going, nor at what he has done.

>> * 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.

It's all a matter of thinking out how to define the macros and other
entities. This is relevant to the manpage issue (see at end).

>> * 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.

I very much agree with this (and do much the same myself). Myself,
I do not have much to do with structured markup, since my approach
is usually along the lines of "do the following precise thing now"
(c.f. "wooden ploughshares" above). When my document has structure,
I create it myself (e.g. leading my horses by hand from one patch
of field to the next).

A lot of this discussion (which I have tended to keep out of, because
it is about issues that rarely concern me; and also has not always
been clear) has been about creating a new, and structured, approach
to the formatting of manpages, especially with reference to making
them browsable. I can grant that there is a need for this.

QUESTION: It has not become clear to me, from this discussion,
to what extent this might interfere with core groff. At times,
Eric Raymond has written as though this would involve a complete
re-make of groff, with the potential inplication that use of groff
for other purposes, and especially documents with "printed-page"
layout, would involve a complete revision of how one would work
with groff (e.g. classical macro sets would themselves become
obsolete); and indeed has hinted that the printed page itself is
becoming obsolete so that there will soon be no need for the
traditional capabilities of {g|t}roff.

SO: Supposing that this proposed enterprise goes ahead, WILL WE
STILL BE ABLE TO USE GROFF AS WE ALWAYS HAVE DONE?

I'm speaking here of non-manpage work. For myself (and other will
certainly think differently), I'm quite happy to enter "man XXXX"
in a terminal and scan through what comes up. If others prefer to
access it differently, that's fine, so long as making it possible
does not interfere with how I use groff!

If there is incompatibility between a new approach to manpages, and
non-manpage traditional use of groff, then I would say: Let the
manpage issue be made completely separate from traditional groff.
A completely separate program "manroff" if necessary! From my point
of view, manpages must not interfere with core groff.

And don't forget that the origins of groff go back to "runoff",
a program originally written for preparation of printed text.
Manpages came a bit layer.

And, finally, a comment about PDF. Some people have deprecated it.
But, if you created a carefully formatted document to send to
someone else, then usually this needs to be in PDF. UNIX/MacOS
and Linux users, if they know what they are doing, can access PS.
But many do no know what thney are doing, and they -- and of course
Windows users -- will only be able to cope with PDF.

I have, in the past, had the experience of sending PS files to
people who opened them in Word (with autosave mode active, of course)
who then (a) could not make sense of what they saw, and (b) screwed
up the original file because autosave arbitrarily overwrote parts of it!

I think PDF is here to stay for quite a long time, and is needed, and
I do not admit "anti-PDF" as arguments for not needing groff->PD->PDF
capability.

>       -- Steve
> -- 
> Steve Izma
> -

Best wishes to all,
Ted.

-------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Date: 19-Mar-2014  Time: 19:01:45
This message was sent by XFMail
-------------------------------------------------