|
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
vertical-motions.roff
Description: vertical-motions.roff
vertical-motions-groff.ps
Description: vertical-motions-groff.ps
vertical-motions-heirloom.ps
Description: vertical-motions-heirloom.ps
vertical-motions-groff.png
Description: vertical-motions-groff.png
vertical-motions-heirloom.png
Description: vertical-motions-heirloom.png
vertical-motions-groff.ditroff
Description: vertical-motions-groff.ditroff
vertical-motions-heirloom.ditroff
Description: vertical-motions-heirloom.ditroff
signature.asc
Description: PGP signature
[Prev in Thread] | Current Thread | [Next in Thread] |