<< . .

. 12
( : 45)



. . >>

in inch (1 in = 2.54 cm) sharped dimensions
bp big point (72 bp = 1 in) de¬ne pixels
hppp
cm centimeter (100 cm = 1 meter) de¬ne blacker pixels
mm millimeter (10 mm = 1 cm)
dd didot point (1157 dd = 1238 pt)
cc cicero (1 cc = 12 dd)
1
In each case the values are rounded to the nearest 65536 th of a pixel.
Although such standard physical dimensions are available, they haven™t
been used very much in traditional typefaces; designers usually specify other
units like ˜em ™ or ˜x height ™ in order to de¬ne the sizes of letters, and such
quantities generally have ad hoc values that vary from font to font. Plain -
makes it easy to introduce ad hoc dimensions that will vary with the
resolution and the magni¬cation just as pt and mm do; all you have to do is
de¬ne “sharped” dimensions that have the same name as your pixel-oriented
dimensions, but with ˜#™ tacked on as a su¬x. For example, em # and x height #
(typed ˜em#™ and ˜x_height#™ ) would be the sharped dimensions corresponding
has already de¬ned the quantities pt #,
to em and x height . Plain
pc #, in #, bp #, cm #, mm #, dd #, and cc # for the standard units named above.
Sharped dimensions like em # and x height # should always be de¬ned
in terms of resolution-independent dimension variables like pt #, in #, etc., so
that their values do not change in any way when mode and mag are varied.
The ˜#™ sign implies unchangeability. After mode setup has been called, the
pixel-oriented dimensions can be calculated by simply saying
de¬ne pixels(em , x height ).
This statement is an abbreviation for
em := em # — hppp ; x height := x height # — hppp
where hppp is an internal variable of that represents the number of
pixels per point in the horizontal dimension. Any number of ad hoc dimensions
can be listed in a single de¬ne pixels statement. Notice that ˜#™ is not an oper-
ator that could convert em to em #; rounding errors would be mode-dependent.
Chapter 5™s demonstration program io.mf contains several examples of
ad hoc dimensions de¬ned in this way, and it also contains the statement
de¬ne blacker pixels(thin , thick );
Chapter 11: Magni¬cation and Resolution 93


what™s this? Well, Appendix B makes that statement an abbreviation for blacker
proof
thin := thin # — hppp + blacker ; thick := thick # — hppp + blacker ; smoke
de¬ne corrected pixels
round
in other words, the sharped dimensions are being unsharped in this case by eps
converting them to pixels and then adding ˜blacker ™. The variable blacker is a o
o correction
special correction intended to help adapt a font to the idiosyncrasies of the cur- overshoot
rent output device; mode setup uses the value of mode to establish the value of ¬llin
corner
blacker . For example, cheapo mode might want blacker = 0.65, while luxo mode
might give best results when blacker = 0.1. The general convention is to add
blacker to pixel-oriented variables that determine the breadth of pens and the
thickness of stems, so that the letters will be slightly darker on machines that
otherwise would make them appear too light. Di¬erent machines treat pixels
quite di¬erently, because they are often based on quite di¬erent physical prin-
ciples. For example, the author once worked with an extremely high-resolution
device that tended to shrink stem lines rather drastically when it used a certain
type of photographic paper, and it was necessary to set blacker = 4 to get proper
results on that machine; another high-resolution device seems to want blacker
to be only 0.2. Experimentation is necessary to tune ™s output to
particular devices, but the author™s experience suggests strongly that such a cor-
rection is worthwhile. When mode = proof or smoke , the value of blacker is
taken to be zero, since the output in these modes is presumably undistorted.
EXERCISE 11.1
Does ˜mode = cheapo ; mag = 10™ produce exactly the same font as ˜mode =
luxo ™, under the assumptions of this chapter?
Line 7 of io.mf says ˜de¬ne corrected pixels(o)™, and this is yet a third
way of converting from true physical dimensions to pixel-oriented values. Ac-
cording to Appendix B, variable o is de¬ned by the assignment
o := round(o# — hppp — o correction ) + eps
where o correction , like blacker , is a magic number that depends on the output device
for which fonts are being made. On a high-resolution device like luxo , the appropriate
value for the o correction factor is 1; but on a low-resolution device like cheapo , the
author has obtained more satisfactory results with o correction = 0.4. The reason is
that ˜o™ is used to specify the number of pixels by which certain features of characters
“overshoot” the baseline or some other line to which they are visually related. High-
resolution curves look better when they overshoot in this way, but low-resolution curves
do not; therefore it is usually wise to curtail the amount of overshoot by applying the
o correction factor. In proof and smoke modes the factor is equal to 1.0, since these
modes correspond to high resolution.
The properties of output devices are modeled also by a parameter that™s called
¬llin , which represents the amount by which diagonal strokes tend to be darker
than horizontal or vertical strokes. More precisely, let us say that a “corner” pixel is
one whose color matches the color of ¬ve of its neighbors but not the other three,
where the three exceptions include one horizontal neighbor, one vertical neighbor, and
94 Chapter 11: Magni¬cation and Resolution


the diagonal neighbor between them. If a white corner pixel has apparent darkness f1 mode
and if a black corner pixel has apparent darkness 1 ’ f2 , then the ¬llin is f1 ’ f2 . (A mode def
proo¬ng
“true” raster image would have f1 = f2 = 0, but physical properties often cause pixels fontmaking
to in¬‚uence their neighbors.) tracingtitles
aspect ratio
Each output device for which you will be generating fonts should be repre- nonsquare
currenttransform
sented by a symbolic mode name in the implementation of that
you are using. Since these mode names vary from place to place, they are not standard
aspects of the language; for example, it is doubtful whether the hypotheti-
cal cheapo and luxo modes discussed in this chapter actually exist anywhere. The plain
base is intended to be extended to additional modes in a disciplined way,
as described at the end of Appendix B.
It™s easy to create a new symbolic mode, using plain ™s ˜mode def ™
convention. For example, the luxo mode we have been talking about could be
de¬ned by saying
mode def luxo =
pixels per inch := 2000; high res, almost 30 per point
%
blacker := .1; make pens a teeny bit blacker
%
o correction := 1; keep the full overshoot
%
¬llin := 0.1; compensate for darkened corners
%
proo¬ng := 0; no, we™re not making proofs
%
fontmaking := 1; yes, we are making a font
%
tracingtitles := 1; enddef ; yes, show titles online
%
The name of the mode should be a single symbolic token. The resolution should be
speci¬ed by assigning a value to pixels per inch ; all other dimension values (pt , mm ,
etc.) will be computed from this one by mode setup. A mode de¬nition should also
assign values to the internal variables blacker , o correction , and ¬llin (which describe
the device characteristics), as well as proo¬ng , fontmaking , and tracingtitles (which
a¬ect the amount of output that will be produced). In general, proo¬ng and fontmaking
are usually set to 0 and 1, respectively, in modes that are intended for font production
rather than initial font design; tracingtitles is usually 0 for low-resolution fonts (which
are generated quickly), but 1 for high-resolution fonts (which go more slowly), because
detailed online progress reports are desirable when comparatively long jobs are running.
Besides the seven mandatory quantities ˜pixels per inch ™, . . . , ˜tracingtitles ™
just discussed, a mode de¬nition might assign a value to ˜aspect ratio ™. In the
normal case when no aspect ratio is speci¬ed, it means that the fonts to be output are
assumed to have square pixels. But if, for example, the mode def sets aspect ratio :=
5/4, it means that the output pixels are assumed to be nonsquare in the ratio of 5
to 4; i.e., 5 vertical pixel units are equal to 4 horizontal pixel units. The pixel-oriented
dimensions of plain are given in terms of horizontal pixel units, so an aspect
ratio of 5/4 together with 2000 pixels per inch would mean that there are 2500 vertical
pixel units per inch; a square inch would consist of 2500 rows of pixels, with 2000 pixels
1 1
in each row. (Stating this another way, each pixel would be 2000 inches wide and 2500
will set the currenttransform variable
inches high.) In such a case, plain
so that all draw and ¬ll commands stretch the curves by a factor of 5/4 in the vertical
dimension; this compensates for the nonsquare pixels, so the typeface designer doesn™t
have to be aware of the fact that pixels aren™t square.
Chapter 11: Magni¬cation and Resolution 95


Let™s look now at a concrete example, so that it will be clear how the logo
parameter
ideas of device-independent font design can be implemented in practice. We
shall study a ¬le logo.mf that generates the seven letters of ™s logo.
There also are “parameter” ¬les logo10.mf, logo9.mf, etc., which use logo.mf
to produce fonts in various sizes. For example, a font containing the 10-point
characters ˜ ™ could be generated for the hypothetical luxo printer by
running with the command line
\mode=luxo; input logo10
if luxo mode really existed.
The main purpose of logo10.mf is to establish the “sharped” values of
several ad hoc dimensions; then it inputs logo.mf, which does the rest of the
work. Here is the entire ¬le logo10.mf:
% 10-point METAFONT logo
font_size 10pt#; % the "design size" of this font
ht#:=6pt#; % height of characters
xgap#:=0.6pt#; % horizontal adjustment
u#:=4/9pt#; % unit width
s#:=0; % extra space at the left and the right
o#:=1/9pt#; % overshoot
px#:=2/3pt#; % horizontal thickness of pen
input logo % now generate the font
end % and stop.
Similar ¬les logo9.mf and logo8.mf will produce 9-point ˜ ™ and
8-point ˜ ™; the letters get a little wider in relation to their height,
and the inter-character spacing gets signi¬cantly wider, as the size gets smaller:
% 9-point METAFONT logo % 8-point METAFONT logo
font_size 9pt#; font_size 8pt#;
ht#:=.9*6pt#; ht#:=.8*6pt#;
xgap#:=.9*0.6pt#; xgap#:=.8*0.6pt#;
u#:=.91*4/9pt#; u#:=.82*4/9pt#;
s#:=.08pt#; s#:=.2pt#;
o#:=1/10pt#; o#:=1/12pt#;
px#:=.9*2/3pt#; px#:=.8*2/3pt#;
input logo input logo
end end
It is interesting to compare the font generated by logo10.mf to the font gener-
ated by logo8.mf with mag=10/8: Both fonts will have the same values of ht ,
xgap , and px , when the magni¬cation has been taken into account. But the
magni¬ed 8-point font has a slightly larger value of u and a positive value of s ;
this changes ˜ ™ to ˜ ™.
96 Chapter 11: Magni¬cation and Resolution


Every font has a “design size,” which is a more-or-less arbitrary number that design size
TeX
re¬‚ects the size of type it is intended to blend with. Users of TEX select
at size
magni¬ed fonts in two ways, either by specifying an “at size” or by specifying a scale font size
factor (times 1000). For example, the 8-point logo can be used at 10/8 savepen
E
magni¬cation by referring either to ˜logo8 at 10pt™ or to ˜logo8 scaled 1250™ in a TEX
document. When an “at size” is speci¬ed, the amount of magni¬cation is the stated
size divided by the design size. A typeface designer can specify the design size by using
plain ™s ˜font size™ command as illustrated on the previous page. (If no
design size is speci¬ed, will set it to 128 pt, by default.)

The ¬le logo.mf itself begins by de¬ning three more ad hoc dimensions
in terms of the parameters that were set by the parameter ¬le; these dimensions
will be used in several of the programs for individual letters. Then logo.mf
makes the conversion to pixel units:
% Routines for the METAFONT logo
% (logo10.mf is a typical parameter file)
mode_setup;
ygap#:=(ht#/13.5u#)*xgap#; % vertical adjustment
leftstemloc#:=2.5u#+s#; % position of left stems
barheight#:=.45ht#; % height of bar lines
define_pixels(s,u,xgap,ygap,leftstemloc,barheight);
py#:=.9px#; define_blacker_pixels(px,py); % pen dimensions
pickup pencircle xscaled px yscaled py; logo_pen:=savepen;
define_corrected_pixels(o);

There™s nothing new here except the use of ˜savepen ™ in the second-last line;
this, as we will see in Chapter 16, makes the currently-picked-up pen available
for repeated use in the subsequent program.
After the initial de¬nitions just shown, logo.mf continues with programs
for each of the seven letters. For example, here is the program for ˜ ™, which
illustrates the use of u#, s#, ht #, leftstemloc , barheight , xgap , and logo pen :

beginchar("E",14u#+2s#,ht#,0);
pickup logo_pen;
x1=x2=x3=leftstemloc;
x4=x6=w-x1+o; x5=x4-xgap;
(Figure 11a will be inserted here;
y1=y6; y2=y5; y3=y4; too bad you can™t see it now.)

bot y1=0; top y3=h;
y2=barheight;
draw z6--z1--z3--z4; draw z2--z5;
labels(1,2,3,4,5,6);
endchar;

We have seen the essentials of the and the in Chapter 4; programs for the
other letters will appear later.
Chapter 11: Magni¬cation and Resolution 97


EXERCISE 11.2 F
M
The ad hoc dimensions ht #, xgap #, u#, s#, o#, and px # de¬ned in the parameter T
¬les all a¬ect the letter ˜ ™ de¬ned by this program. For each of these dimensions, kerning
kern
tell what would happen to the ˜ ™ if that dimension were increased slightly while ligtable
all the others stayed the same. font quad
font normal space
EXERCISE 11.3 font normal stretch
font normal shrink
Guess the program for ˜ ™ (which is almost the same as ˜ ™ ). =
:=
EXERCISE 11.4 ligtable
Write the complete programs for ˜ ™ and ˜ ™, based on the information in
Chapter 4, but using the style of the program for ˜ ™ above. The character widths
should be 18u# + 2s# and 13u# + 2s#, respectively.
The ¬le logo.mf also contains the following cryptic instructions, which cause
the letter pairs ˜ ™ and ˜ ™ to be typeset closer together than their bounding
boxes would imply:
ligtable "T": "A" kern -.5u#;
ligtable "F": "O" kern -u#;

Without these corrections ˜ ™ would be ˜ ™. Uppercase letters
are often subject to such spacing corrections, especially in logos; TEX will adjust the
spacing if the typeface designer has supplied ligtable information like this.
Finally, logo.mf closes with four more commands, which provide further in-
formation about how to typeset with this font:
font_quad 18u#+2s#;
font_normal_space 6u#+2s#;
font_normal_stretch 3u#;
font_normal_shrink 2u#;
A font quad is the unit of measure that a TEX user calls one ˜em™ when this font is
selected. The normal space, stretch, and shrink parameters de¬ne the interword spacing
when text is being typeset in this font. Actually a font like logo10 is rarely used to
typeset anything except the one word, ˜ ™; but the spacing parameters have
been included just in case somebody wants to typeset a sentence like ˜
™.
An optional ˜=™ or ˜:=™ sign may be typed after ˜font size™, ˜font quad™, etc.,
in case you think the ¬le looks better that way.
Notice that “sharped” units must be given in the ligtable kerning commands
and in the de¬nition of device-independent parameters like font size and
font quad. Appendix F discusses the complete rules of ligtable and other commands
by which programs can send important information to typesetting systems
like TEX. Adding these extra bits of information to a program after a font
has been designed is something like adding an index to a book after that book has been
written and proofread.
EXERCISE 11.5
What™s the longest English word that can be typeset with the font logo9?
98 Chapter 11: Magni¬cation and Resolution


Let™s summarize the general contents of logo.mf, now that we have seen it ligtable
font quad
all, because it provides an example of a complete typeface description (even
meta-font
though there are only seven letters): Assignments
magstep
The ¬le begins by de¬ning ad hoc dimensions and converting them to pixel
TeX
units, using mode setup, de¬ne pixels, etc.
Then come programs for individual letters. (These programs are often pre-
ceded by macro de¬nitions for subroutines that occur several times. For ex-
ample, we will see later that the ˜ ™ and the ˜ ™ of the logo are drawn with the
help of a subroutine that makes half of a superellipse; the de¬nition of this
macro actually comes near the beginning of logo.mf, just before the programs
for the letters.)
Finally there are special commands like ligtable and font quad, to de¬ne
parameters of the font that are helpful when typesetting.
The ¬le is accompanied by parameter ¬les that de¬ne ad hoc dimensions for
di¬erent incarnations of the typeface.
We could make lots of di¬erent parameter ¬les, which would produce lots of di¬erent
(but related) variations on the logo; thus, logo.mf de¬nes a “meta-font”
in the sense of Chapter 1.
EXERCISE 11.6
What changes would be necessary to generalize the logo routines so that the
bar-line height is not always 45 per cent of the character height?
Assignments ( ˜:=™ ) have been used instead of equations ( ˜=™ ) in the param-
eter ¬les logo10.mf, logo9.mf, and logo8.mf, as well as in the opening lines
of io.mf in Chapter 5; this contradicts the advice in Chapter 10, where we are told to
stick to equations unless assignments are absolutely necessary. The author has found
it convenient to develop the habit of using assignments whenever ad hoc dimensions
are being de¬ned, because he often makes experimental ¬les in which the ad hoc di-
mensions are changed several times. For example, it™s a good idea to test a particular
letter with respect to a variety of di¬erent parameter settings when that letter is ¬rst
being designed; such experiments can be done easily by copying the ad hoc parameter
de¬nitions from parameter ¬les into a test ¬le, provided that the parameters have been
de¬ned with assignments instead of equations.
TEX users have found it convenient to have fonts in a series of magni¬cations
that form a geometric series. A font is said to be scaled by ˜magstep 1™ if
it has been magni¬ed by 1.2; it is scaled by ˜magstep 2™ if it has been magni¬ed by
1.2 — 1.2 = 1.44; it is scaled by ˜magstep 3™ if it has been magni¬ed by 1.2 — 1.2 — 1.2 =
1.728; and so on. Thus, if a job uses a font that is scaled by magstep 2, and if that
entire job is magni¬ed by magstep 1, the font actually used for printing will be scaled
by magstep 3. The additive nature of magsteps makes it more likely that fonts will
exist at the desired sizes when jobs are magni¬ed. Plain supports this
convention by allowing constructions like
\mode=cheapo; mag=magstep 2; input logo9
logo for the cheapo printer, magni¬ed
if you want to generate the 9-point
by 1.44 (i.e., by magstep 2). You can also write ˜magstep 0.5™ for what TEX calls

˜\magstephalf™; this magni¬es by 1.2.
Chapter 11: Magni¬cation and Resolution 99


The sharped forms of dimensions are actually represented by plain - BURKITT
#™ turns out to be equal to 1. SWIFT
in terms of printer™s points, so that ˜pt
However, it is best for programmers not to make use of this fact; a program ought to
say, e.g., ˜em # := 10pt #™, even though the ˜pt #™ in this construction is redundant, and
even though the computer would run a few microseconds faster without it.
EXERCISE 11.7
Suppose you want to simulate a low-resolution printer on a high resolution
device; for concreteness, let™s say that luxo is supposed to produce the output of cheapo ,
with each black cheapo pixel replaced by a 10 — 10 square of black luxo pixels. Explain
how to do this to the logo10 font, by making appropriate changes to logo.mf. Your
output ¬le should be called cheaplogo10.2000gf.




A great Temptation must be withstood with great Resolution.
” WILLIAM BURKITT, Expository Notes on the New Testament (c. 1700)

What some invent, the rest enlarge.
” JONATHAN SWIFT, Journal of a Modern Lady (1729)
(page 100)




12
Boxes
Chapter 12: Boxes 101


Let™s pause now to take a closer look at the “bounding boxes” that enclose TeX
height
individual characters. In olden days, metal type was cast on a rectangular body baseline
in which each piece of type had the same vertical extent, although the type widths depth
width
would vary from character to character. Nowadays we are free of the mechanical reference point
constraints imposed by metal type, but the former metaphors are still useful: cmr10
cmsl10
A typesetting system like TEX imagines that each character ¬ts into a rectangular
box, and words are typeset by putting such boxes snugly next to each other.
The main di¬erence between the old conventions and the new ones is that
type boxes are now allowed to vary in height as well as in width. For example,
when TEX typesets ˜A line of type.™ it puts boxes together that essentially look
like this: ˜ ™. (The ˜A™ appears in a box ˜ ™ that sits on a given
baseline, while the ˜y™ appears in a box ˜ ™ that descends below the baseline.)
TEX never looks inside a box to see what character actually appears there; TEX™s
job is to put boxes together in the right places on a page, based only on the box
sizes. It is a typeface designer™s job to decide how big the boxes should be and
to create the characters inside the boxes.
Boxes are two-dimensional objects, but we ascribe three dimensions to
them because the vertical component is divided into two quantities, the height
(above the baseline) and the depth (below the baseline). The horizontal dimen-
sion is, of course, called the width. Here is a picture of a typical box, showing
its so-called reference point and baseline:

|
|

<< . .

. 12
( : 45)



. . >>