Re: Should vertical motions be in vees or ems? Where does the baseline go?

[G. Branden Robinson]

At 2021-11-22T23:06:38-0500, Douglas McIlroy wrote:
> > This [disagreement in position of a drawn baseline]
> > seems like a bug in Heirloom Doctools troff to me, but given that
> > code base's provenance, it's easily possible that it's better aligned
> > with AT&T troff behavior.  (Does someone know?)
> 
> I don't know absolutely, but it's very likely that both groff and
> heirloom agree with one "AT&T troff'' or another.

I would not be at all surprised.  I earlier compared certain attitudes
to that of fundamentalist evangelicalism.  A lot of people who tout the
Bible at you get frustrated when you ask whether they mean the King
James or the New International Version or whatever.  With AT&T troff,
there's more than one authoritiative source to cite, and as with most
topics of nontrivial complexity, these sources sometimes conflict.

> Ossanna's original did not have drawing capability, so it created
> horizontal lines as a row of underscores. The vertical position and
> thickness of such a line is determined by the current font. Later, in
> ditroff, Kernighan introduced \D drawing capability. Then the position
> and thickness of the line became the baseline and the current point
> size.

With some swift cleanup work, John Gardner got cat2dit working for me,
and the results are interesting.  I won't say that they're more than
suggestive, because (1) we don't know that cat2dit itself is flawless,
and (2) there is more I need to understand, I'm sure.  But as a
translation of V7 Unix troff output into something modern eyes can read
(after absorbing groff_out(5) or similar), it's valuable.

An exegesis of cat2dit(1) output from an early version of my vertical
movement demo follows.  Those likely to be bored are advised to bail out
now.

First, the input.

        .sp 2v
        \l'\n(.lu'\h'|0'
        Ofoo\dbar\rbaz\dqux
        foo\dbar\u\ubaz\dqux
        foo\v'0.5v'bar\v'-1v'baz\dqux
        foo\v'0.5m'bar\v'-1m'baz\dqux

Now, the C/A/T output translated to device-independent troff.

        x T cat
        x res 432 1 3
        x init

I had no luck pasting this into John's web-demo viewer, possibly because
it's expecting output for the 'pdf' device as it explicitly claims.

        p1
        x font 1 R
        x font 2 I
        x font 3 B
        x font 4 S
        f1
        s10

So far this looks highly idiomatic.

        v31
        v31
        v10
        h127
        h127
        h127

I think we see the legacy of signed char use for storage of magnitudes
here, though why vertical magnitudes are more limited that horizontal
ones is a curious post.

        h35
        Cul
        wh18

The first chunk of horizontal rule is rendered exactly as Doug said,
with a 'ul' special character.

        Cul
        wh30

The foregoing is repeated many times.  The 'w' prefix is interestingly
misleading, since there's no word separation.  Is this a cat2dit bug?

        wh-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-127
        h-91

Having reached the end of the line, we step back to the beginning of it.
Were no "absolute" motions (H, V) supported by the C/A/T's command
language?

        cO
        wh45
        cf
        wh22
        co
        wh33
        co

We write the letter "O" (for "otroff") and then "foo".  Again note the
misleading "w" prefixes.

        wv10
        h33
        cb
        wh33
        ca
        wh28
        cr
        wv-20
        h23
        cb
        wh33
        ca
        wh28
        cz
        wv10
        h28
        cq
        wh32
        cu
        wh35
        cx

"bar", "baz" and "qux" are written with vertical motions.  A "w" prefix
on a vertical motion is an interesting idea.  I'm not sure it makes
sense?  In any case, the magnitudes are:

\d -> 10
\r -> -20

Here's the 2nd "foobarbazqux".

        wh53
        cf
        wh22
        co
        wh33
        co
        wv10
        h33
        cb
        wh33
        ca
        wh28
        cr
        wv-20
        h23
        cb
        wh33
        ca
        wh28
        cz
        wv10
        h28
        cq
        wh32
        cu
        wh35
        cx

\d -> 10
\u\u -> -20

That's an interesting optimization given how pessimal the rest of the
output is.

Group three, manual \v motions in VEES (ultra-wrong! bad dog!).

        wh53
        cf
        wh22
        co
        wh33
        co
        wv12
        h33
        cb
        wh33
        ca
        wh28
        cr
        wv-24
        h23
        cb
        wh33
        ca
        wh28
        cz
        wv10
        h28
        cq
        wh32
        cu
        wh35
        cx

\v'0.5v' -> 12
\v'-1v' -> -24

Indeed different, though nearing the resolution limit of the device (or
the command language, or the ditroff translation thereof).

Finally, group four, with manual \v motions in ems.

        wh53
        cf
        wh22
        co
        wh33
        co
        wv10
        h33
        cb
        wh33
        ca
        wh28
        cr
        wv-20
        h23
        cb
        wh33
        ca
        wh28
        cz
        wv10
        h28
        cq
        wh32
        cu
        wh35
        cx

Once again, motions of 10 and -20 basic units/device units.  This indeed
vindicates the claims of CSTR #54 for those like me who want to verify
its claims but are too thick to comprehend Ossana's C code at a glance.

        wv31
        x trailer
        x stop

John shared some USENET lore from the '80s that does much to explain why
device-independent troff had the pre- and postambles that it does.

https://github.com/Alhadis/otroff/blob/92683053f9aad5b926fc447843bf2092ad59cebf/cat.5

I sure wish we could get our hands on full v3 and v4 Unix manuals.  This
bit of groff's roff(7) page is the part I'm saddest about.

       Third Edition Unix also brought the pipe(2) system call, the
       explosive growth of a componentized system based around it, and a
       “filter model” that remains perceptible today.  Around this time,
       Michael Lesk developed the tbl preprocessor for formatting
       tables.  Equally importantly, the Bell Labs site in Murray Hill
       acquired a Graphic Systems C/A/T phototypesetter, and with it
       came the necessity of expanding the capabilities of a roff system
       to cope with proportionally-spaced type, multiple type sizes, and
       a variety of fonts.  Ossanna wrote a parallel implementation of
       nroff for the C/A/T, dubbing it troff (for “typesetter roff”).
       Unfortunately, surviving documentation does not illustrate what
       requests were implemented at this time for C/A/T support; the
       troff(1) man page in Fourth Edition Unix (November 1973) does not
       feature a request list, unlike nroff(1).  Apart from typesetter-
       driven features, Version 4 Unix roffs added string definitions
       (.ds); made the escape character configurable (.ec); and enabled
       the user to write diagnostics to the standard error stream (.tm).
       Around 1974, empowered with multiple type sizes, italics, and a
       symbol font specially commissioned by Bell Labs from Graphic
       Systems, Brian Kernighan and Lorinda Cherry implemented eqn for
       typesetting mathematics.  In the same year, for Fifth Edition
       Unix, Ossanna combined and reimplemented the two roffs in C,
       using preprocessor conditions of that language to generate both
       from a single source tree.

A timeline of escape sequence definitions is another thing I'd like to
write, but source materials seem to be lacking.

Regards,
Branden

signature.asc
Description: PGP signature