[Top][All Lists]

[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 14:20:39 +1100
User-agent: NeoMutt/20180716

Following up...

I've researched this issue to my satisfaction, even though I couldn't
get John Garnder's node.js-based V7 troff output decoder working in an
environment available to me.

I've also some up with a better demonstration, which illustrates
Tadziu's point clearly.  You can find the following attachments, in the
spirit of "show, don't tell".

1. the input demo file
2. groff-generated PostScript output from that input file
3. Heirloom Doctools troff-generated PostScript output from that input
4. a screenshot of 2
5. a screenshot of 3

So, I'll be fixing groff(7) and changing our Texinfo manual to align
with it.

That leaves only the apparent baseline discrepancy between groff and

At 2021-11-18T10:31:00+0000, Bjarni Ingi Gislason wrote:
> On Thu, Nov 18, 2021 at 03:23:39PM +1100, G. Branden Robinson wrote:
> [...]
> > 
> > Anyone feel game to tackle the groff/Heirloom baseline rule
> > discrepancy?  :D
>   The difference is caused by a defective viewer.

I was skeptical of this claim and I believe I was right to be so.

If you look at the device-independent output generated by groff and
Heirloom Doctool troff, respectively, you will see that they approach
the problem of drawing a baseline rule across the page quite

Here's the input in question.


groff produces a series of line-drawing commands.

        Dl 5000 0
        Dl 5000 0
        Dl 5000 0
        Dl 5000 0
[repeated many times]

Heirloom Doctools troff writes baseline rule _glyphs_.

        x font 9 S1
[repeated many times]

I'm including two more attachments, the device-independent output of
groff and Heirloom Doctools troff, to further illustrate this.

Unfortunately, on Heirloom, the 'ru' glyph drawn from the 'S1' font
doesn't appear to really sit on the baseline.  As far as my eyes can
tell, it's identical to the '_' glyph, but not the 'ul' glyph (which
sits even lower).

In groff, all three glyphs are distinguishable on typesetter devices,
and the following input arranges them in descending order (on terminals,
they're all the same: '_').


This 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?)

One could also argue, maybe, that the \l (and \L) escape sequences
should not be translated to drawing commands in the device-independent
output, but should instead honor their nroff heritage and draw a series
of glyphs (as they still do if given a second argument).  In
groff_char(7), though, we document the baseline rule as a font-invariant
glyph (meaning that it's rendered using drawing commands).


Attachment: vertical-motions.roff
Description: vertical-motions.roff



Attachment: vertical-motions-groff.png
Description: vertical-motions-groff.png

Attachment: vertical-motions-heirloom.png
Description: vertical-motions-heirloom.png

Attachment: vertical-motions-groff.ditroff
Description: vertical-motions-groff.ditroff

Attachment: vertical-motions-heirloom.ditroff
Description: vertical-motions-heirloom.ditroff

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]