Re: [Groff] troff syntax and useability

[Peter Schaffter]

Hi.

This is a long post, and contains no useful information, just
reflections.  Skip it if you're pressed for time. :)

On Tue, Aug 27, 2002, David Given wrote:
> I wrote my meta macro package because I couldn't cope with the troff
> command set, and none of the other macro packages out there were at all
> useable. The richest macro set is mom, and even that seems to be rooted
> in the 80s (no offense meant! mom is still loads better than meta).

No offense taken. :)  Mom is, in fact, "rooted in the 80s" on purpose.

I apprenticed as a typesetter in the early 80s, back when we had
big, clunky "typesetting computers" -- AM, Compugraphic, Quaditrek,
Linotronic.  These machines all had their own operating systems, and
were designed to do only one task: set type.  (Hard to imagine nowadays,
I know, but once upon a time, there were dozens of these single-task
behemoths.)  They weren't easy to use: text was formatted with codes (a
la troff/groff), but unless one worked for a very wealthy shop, most
of the formatting was done blind.  No "soft previewing," since that
technology was a) in its infancy, and b) costly as hell.  Consequently,
you didn't get to see if you'd screwed up until you processed the galley
-- and galleys weren't cheap!

The advantage to these old machines was they were designed by
typesetters, for typesetters, with only one purpose in mind: to set
high-quality type.  The paradigm for the coding used by these systems
was hot-metal type, and presupposed an in-depth knowledge of the whole
craft of typesetting.  The result (mostly) was that anyone knowledgable
about type could reasonably ask, concerning any given machine, how do I
do x, y, or z? (where x, y, or z was a typesetting procedure known to
all typographers) and expect a comprehensible solution.

Another advantage was that these machines all had "status" lines that
provided essential (old hot-metal style) information: font, point size,
line length, depth on the galley (either from the top or from a marked
point), which tab was currently in use, any active indents, and how much
of a line was taken up by type at any point in the line (absolutely
essential for hyphenating and track kerning individual lines when the
default hyphenation/letterspacing/wordspacing -- already more advanced
than what groff/troff offers even now in 2002! -- needed tweaking.)

The disadvantages to these machines were a) that you couldn't preview
your work prior to printing off a costly galley (which had the upside
that you really had to know what you were doing; mistakes cost a lot of
money), and b) that document processing _per se_ was virtually unknown.
And forget inserting an image (or even, in the early days, the simplest
kind of vector graphic) into a galley.

When, in the early 90s, I went to work for a shop in Montréal that
was experimenting with Macintoshes for high quality type (and believe
me, at the time, the idea "high quality type off a PC" was laughed
at by the typographic establishment), I found the switch to WYSIWYG
difficult.  On the one hand, I had soft previewing capabilities, which
was certainly good for the nerves (no more wondering if errors were
going to be taken off my paycheck).  On the other, I found many of the
most basic typesetting procedures difficult to accomplish, and, more
importantly, difficult to alter.  Complex tabs, especially, were hell
to set up, and even harder to manipulate when, inevitably, proofs came
back to the shop with changes from the designer.  It was my introduction
to what I consider the fundamental liability of WYSIWYG in professional
typesetting: the absence of (or difficulty accessing) text-visible
formatting codes, with the unavoidable result that while a first-off
proof could (sometimes) be produced in less time than with a dedicated
typesetting machine, changes to that proof took vastly more time.

The clear advantages to embedding typesetting code in text has kept me
running a personal rearguard action ever since.  Via a somewhat tortuous
route, I moved from Macintoshes to PCs, and thence, about six years ago,
to running a GNU/Linux system, whence I first encountered groff, and
breathed a sigh of relief: "Ah, at last, a typesetting program I can
use on my PC that works like the sensible machines of old."  My relief
proved premature.  That groff was _capable_ of meeting my typesetting
requirements -- and very powerfully at that -- did not mean it behaved
in a typographically sensible manner.  However, having experience with
old-style computer phototypesetting, circa 1980, it wasn't much of a
leap to come up with the idea of recreating that experience via a macro
set, with groff as the underlying typesetting engine.
 
> meta was designed to completely wrap the details of troff markup. The
> goal was to be able to give it a document in plain ASCII, newlines
> between paragraphs, and it would Just Work. I wanted it to be able to do
> _underlining_ and *italics* automatically, too, but I don't think those
> are on the cards without a preprocessor.

Interesting, in that we're on the same track.  mom, too, tries to
"wrap" the details of troff markup.  And in document processing, to
make it possible to "just write" and have groff "just work."  (mom uses
the .PP macro to begin paras, but a simple .blm PP makes double-spaced
paragraphs in a text editor a perfectly workable option.)

And within the limitations of groff, mom does a pretty good job with
"automatic" underlining/italics.  Mind you, I still wouldn't mind a
groff request that simply underlines type.  In other words, .ul means
"underline" regardless of how groff's invoked.

> (The reason why I've stuck with troff is that it's got an incredibly
> sexy set of input filters. tbl! eqn! pic! tbl! grap! [Although the names
> *do* seem to have been inspired by Pinky...] When dealing with *real
> world text*, troff plus these input filters plus some basic scripting
> can do some of the most amazing things. The output quality is excellent,
> too, beating most word processing programs into a cocked hat.)

Oh, yes.  Absolutely.  However, one place where groff is still
deficient -- and I've discussed this with Werner under separate cover
-- is that groff justifies text only by stretching wordspacing and/or
by hyphenation, whereas a mature typesetting system will stretch
(and/or shrink!) both wordspacing and letterspacing, with defaults AND
user controllable settings.  Werner's plate is full right now, so
anything like this is somewhere off in the distant future.

One last point.  Back in the 90s, working for the shop in Montréal I
refered to above, we experimented with a complete typesetting system
for Macs called "Quoin."  (So complete it involved purchasing a special
Quoin keyboard.)  Quoin's huge advantage was that it permitted
simultaneous WYSIWYG typesetting and old-style, embedded coding
typesetting.  Via a screen which could be split, one could either
manipulate a rendered page (in the manner of, say, Quark XPress) or
work in text-mode with visible, embedded codes.  Any change to either
the rendered image or the text-mode codes resulted in an immediate
update of the other.  For example, highlighting a couple of words in
the WYSIWYG screen and choosing, from a menu, to set them two points
larger, resulted in the visible, embedded, text code being updated to
reflect the change.  A change to the text-coding resulted in the
rendered page being updated.  Case of "the best tool for the job";
there are times, especially in complex page layout, when eyeballing is
way more efficient than coding, and there are times when coding beats
WYSIWYG by a country mile.

Unfortunately, Quoin proved too buggy and we had to scrap it, but I've
always wondered why this obvious solution to the "which is better --
WYSIWYG page layout or Unix-style text processing" hasn't been pursued.

-- 
PTPi
Peter Schaffter
31, Curé-André-Préseault
Appt. 22
Gatineau (Québec)
CANADA  J8T 6E4

A confirmed GNU/Linuxer. Sorry, I don't do Windows.