[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should vertical motions be in vees or ems? Where does the baseline g
From: |
G. Branden Robinson |
Subject: |
Re: Should vertical motions be in vees or ems? Where does the baseline go? |
Date: |
Tue, 23 Nov 2021 20:51:17 +1100 |
User-agent: |
NeoMutt/20180716 |
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