[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU troff output and font metrics demystified (was: Greek letters no

From: joerg van den hoff
Subject: Re: GNU troff output and font metrics demystified (was: Greek letters not slanted in -Tps eqn output)
Date: Tue, 9 Aug 2022 14:08:43 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

second time with complete list of addressees ...

hi branden,

thank you for this background info. really appreciated. I was aware of part of 
but definitely not all of it.

out of curiosity: if I get this right, presence and usage of the t-command
thus excludes any application of microtypography tweaks like those heirloom
troff is capable of, correct? but groff _could_ do it by avoiding the t-command
(which it seems to be able to do if I understand you correctly)?

but regarding my initial problem of erroneous rendering of something like

alpha beta gamma delta sigma rho 1 over 2

I continue to _not_ see how and why exactly the 1/2 gets misformatted and
why the digits are increasingly shifted off to the right of the fraction bar
when more greek letters are put in front (and SS is not found and silently 
by S etc.)


On 08.08.22 22:54, G. Branden Robinson wrote:
[looping in main groff list since I went into didact mode]

Hi Joerg,

At 2022-08-08T21:32:24+0200, joerg van den hoff wrote:
I think I nearly get it now regarding font selection. but regarding
font metrics: my rudimentary understanding was/is that each glyph
essentially gets assigned a rectangle ("bounding box" of the glyph)
and that troff just arranges those boxes next to each other without
gap or overlap, usually?

A "bounding box" for a glyph is a useful concept to have in mind when
designing or producing metrics for a font, but I think it has less
utility when attempting to reason about what troff actually _does_.

If you review the groff_out(5) man page or "gtroff Output" node of our
Texinfo manual, you can get some background on this subject.  (Some of
the writing is subpar IMO--it's an area I have not yet revised to my

Consider a simple example.

$ echo foo | groff -Z
x T ps          # output is for 'ps' (PostScript) device
x res 72000 1 1 # set up resolution & horiz., vert. motion quanta
x init          # begin document
p1              # set page number
x font 5 TR     # mount Times Roman font at position 5
f5              # select font position 5 for printing
s10000          # set type size in basic units (= 10 points)
V12000          # move vertically to y=12,000 units
H72000          # move horizontally to x=72,000 units
md              # set default stroke color
DFd             # set default fill color
tfoo            # output letters 'f', 'o', 'o', advancing each time
n12000 0        # declare presence of line break (documentary)
x trailer       # end document
V792000         # more vertically to page bottom (to cause an ejection)
x stop          # end of troff output

The 't' command is where the real work of writing the glyphs is taking
place.  And as a matter of fact, this command did not exist in AT&T
device-independent troff--it's a groff extension.  In an early version
of AT&T troff, something like the following might have been produced.[1]

cf      # format glyph 'f'
h3330   # move right 3,3000 units
co      # format glyph 'o'
h5000   # move right 5,000 units
co      # format glyph 'o'
h5000   # move right 5,000 units

Here we see that each glyph is formatted and then the drawing position
moved by its width according to font description file, and scaled for
the type size of 10 points.  If we look at the description of the Times
Roman font, go down to the "charset" section which contains the metrics,
and consult the ones for "f" and "o", you will see that the first values
declared are "333" and "500", respectively.  That's at a type size of 1
point, and we're at 10 points, hence the multiplication.

In truth, AT&T's numbers weren't as large because the device resolutions
were not as high.  You can read more about this in groff_font(5), which
I _have_ revised for clarity, so if anything there is vague, that's a
bug in my writing (or my understanding)--please let me know.

But you can begin to see why AT&T stopped doing it this way.  In a
typical document, command pairs like this are going to be the bulk of
troff output.  The short version of a longer story told in CSTR #97 is
that Kernighan introduced an optimization, one which was inapplicable to
glyphs requiring motions expressible with 3 or more digits.  So James
Clark (as far as I know) came up with the 't' command, which relied upon
the output driver (like grops(1)) to look up the glyph widths and scale
them to the type size for itself.  As a bonus, it made the formatted
output text much easier to locate in GNU troff output.

The work of rendering a glyph is delegated to the output driver.  We ask
for a glyph from a certain typeface of a specified color and size, and
the output driver does what it is necessary; it may further delegate
some tasks to a PostScript or PDF interpreter.

You'll note that nowhere in this presentation did the notion of a
"bounding box" come up.  A bounding box is a sort of fiction that helps
us to achieve agreeable placement of drawing elements when laying out a
page.  All GNU troff output knows to say is, "move HERE and write THIS".


[1] This exhibit is very close to what GNU troff _does_ produce if you
     comment out the "tcommand" directive in the font/devps/DESC file.
     The difference is that is that the output is "packed" a bit with
     multiple commands on one line, which is permitted by the syntax in
     many cases.  I admit I'm tempted to change this for readability.

     n12000 0

reply via email to

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