groff
[Top][All Lists]
Advanced

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

GNU troff output and font metrics demystified (was: Greek letters not sl


From: G. Branden Robinson
Subject: GNU troff output and font metrics demystified (was: Greek letters not slanted in -Tps eqn output)
Date: Mon, 8 Aug 2022 15:54:48 -0500

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

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

Regards,
Branden

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

    DFd
    cfh3330
    coh5000
    coh5000
    n12000 0

Attachment: signature.asc
Description: PGP signature


reply via email to

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