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

[John Gardner]

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


Not a bug, but a hack on my part. See, Roff.js (currently) relies on `w`
instructions to tell when a word has finished being printed, something
which is necessary because of the way it buffers characters in memory (to
avoid the jarring gaps resulting from the system's font metrics differing
ever-so-slightly from those used by Groff's output driver; this becomes
especially visible in long-running spans of text).

The C/A/T didn't *have* an instruction for indicating a word-break (nor
would having one make much sense, as this instruction is purely
informational in nature). Hence, you can safely ignore those `w` additions.
;-)

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

I added a -T option to cat2dit(1) for this very reason. Try this:

/path/to/cat2dit -Tpdf < cat.out


On Tue, 23 Nov 2021, 8:51 pm G. Branden Robinson, <
g.branden.robinson@gmail.com> wrote:

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