groff
[Top][All Lists]
Advanced

[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
   file
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
Heirloom.

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

Here's the input in question.

        \l"\n(.lu"\h"|0"\c

groff produces a series of line-drawing commands.

[...]
        H72000
        Dl 5000 0
        H75000
        Dl 5000 0
        Dl 5000 0
        Dl 5000 0
[repeated many times]

Heirloom Doctools troff writes baseline rule _glyphs_.

[...]
        x font 9 S1
[...]
        H720
        f9
        V600
        Cru
        h30Cru
        h50Cru
        h50Cru
        h50Cru
        h50Cru
[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: '_').

        A\C'ru'_\C'ul'B

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

Regards,
Branden

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

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

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

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]