AAT Font Quality Specification
INSTRUCTING / HINTING
Overview:
Several techniques must be used for good hinting. When these techniques
are used for hinting, fonts display well and are easier to maintain. Fonts
have to be instructed for both the screen (usually 72dpi) and the printer
(usually 300dpi). Although available printer resolutions are improving
all the time, with 360, 400, 600, 800, and 1200dpi printers commonly available,
it is still important to test for the lowest common denominator, i.e. 300dpi
with no smoothing or dot size enhancement (Apple's PhotoGrade, for example).
300dpi is still the current standard resolution for most laserprinters.
In addition, if a font looks good at 300dpi, it is almost guaranteed to
look better at higher resolutions.
At times, instructing for the screen gets ignored. However, the effort
should be spent, because legibility on screen is just as important as legibility
in print, even though it is more difficult to achieve.
The different strokes as described earlier should be controlled both
for the screen and for the printed output. For example, the stems for uppercase
and lowercase should be controlled similarly for both screen and printed
output.
The diagonals should also be controlled effectively. There should be
no drop-outs or 'pinched' areas, where stems taper to the point where there
are no pixels representing it (see figure 3-1). When diagonal strokes are
intended to be straight, and/or at small screen sizes, they should not
taper or flair at the stroke's ends, and should have even, parallel sides,
with consistent stairstepping pixels. Where a diagonal crosses another
stroke (in a y, x or Q, for examples), both segments of the diagonal should
align both at their intercept point and in their angle, so that the stroke
looks continuous and not as though it were made up of two unrelated parts.
There should be no stray pixels, which result in a moth-eaten or shaggy
look.
fig. 3-1 Drop-out (pinching) occurring at an uncontrolled narrow point
Heights should be uniform at small sizes. There should not be any expansion
or squishing, especially in CJK fonts where the glyphs must stay in the
bounding box. Improper height control will result in wavy lines of text.
Spacing should look clean and regular. There should not be excessive
white space between glyphs, nor should glyphs collide, unless specifically
desired as part of the look of the typeface. Columnating numerals should
all have the same spacing. Similar glyphs (period and comma, colon and
semicolon, base and component glyphs) should all have the same spacing
as well.
For CJK fonts, approximately 5% white space should be left between the
em- square and all sides of the body of the glyph. See figure 3-2.
fig. 3-2 CJK Whitespace
The white space inside contours must also be maintained. Similar contours
(radicals and elements for CJK fonts) should be instructed using the same
techniques, preferably with the same instructions. Elements that are instructed
the same will look the same. For example, the dots of the Roman 'i' and
'j' should be instructed using the same approach, as should the bowls of
the 'b', 'd' and 'p'. (This also saves time and effort, as the typographer
can often copy and paste portions of the instructions from one glyph to
another.)
Math characters (plus, minus, divide, etc.,) should have their horizontal
strokes align properly and have the same weight. Symmetrical glyphs (dots,
periods, degree symbol, plus sign, etc.) should maintain symmetry at all
sizes, assuming that that is the intention of the design.
Text "color" is also important. When reading reasonably homogeneous
blocks of text, no glyphs should stand out as excessively light or dark,
as this detracts from the readability of the text. The usual method for
checking this (for Roman fonts) is examining paragraphs of text in all
caps, all lower case, and mixed upper and lowercase formats (see the detailed
examples below). Test text should also include figures and normal punctuation.
Summary of tasks:
Instruction proofing requires "waterfalls", which are different
from the earlier outline proofing documents. Waterfalls are used chiefly
to inspect instruction integrity over a range of sizes and output resolutions.
Even though the designer is using the same merged font, s/he is looking
specifically at glyph hinting, not outlines in context. There is limited
overlap.
Examples:
Current (non-AAT) waterfalls:
(Each line is waterfalled through sizes 6-30ppem)
Technical details:
These require 72 and 300dpi raster devices (i.e., a screen and a non-PostScript
printer with all features such as variable pixel size turned off).
Family attributes
The typographer should keep in mind family attributes while working
on fonts. Glyph heights (cap-, x- and fig-heights, for example), transition
sizes (the size at which a stem breaks from one pixel to two, or two to
three), etc., should be considered for consistency throughout a family,
which may consist of Roman, Bold, Italic, Bold Italic, and possibly other
variations.
An example often noticed when examining waterfalls is, if a Roman font
breaks from two to three pixels at 18ppem (pixels per em, equivalent to
points at 72dpi), and the bold font breaks from three to four pixels at
19ppem, then at 18ppem both fonts will have the same visual weight. See
figure 3-3 for this example of potentially confusing breaking.
fig. 3-3 Roman/Bold
Note that at 18ppem, both glyphs look identical. If both fonts are made
to break to the next pixel thickness at 18ppem, this problem is avoided.
(This example is for demonstration purposes only, and is not to scale.)
Obliquing, emboldening, and style limiting; font classification
For some fonts, no true italic or bold style is included, but an obliqued
or smear- emboldened style is created by the Macintosh on demand. This
is more likely with, but not limited to, a sans serif font such as Helvetica
or Avant Garde, both of which are obliqued by the computer on the fly.
The designer should be aware of this when designing a font family for which
the range of available styles will be more limited than the standard Regular,
Italic, Bold, and Bold Italic styles. In addition, the designer should
be aware that the user always has these styling options available, whether
using them is typographically correct or not. The examples shown in figure
3-4 are all fonts where the style(s) selected (either bold, italic, or
both) do not exist as true typefaces, forcing the system to algorithmically
generate the style as best it can. As can be seen, the results are mixed.
fig. 3-4 Font as designed/Font styled by the system. Some fonts work
better than others.
The Font Classification in the 'fond' must be set correctly, so that
the system can recognize the capabilities of the fonts within the family
suitcase. This is done in ResEdit. Otherwise, family relationships between
fonts will not be recognized, and fonts will not italicize or embolden
when required.
The procedure for using ResEdit to change the Font Classification in
an 'sfnt' is as follows:
To find the correct value for Font Classification, use the following
table (figure 3-5).
fig. 3-5 Roman character set Font Classification table.
(NOTE) Table 3-5 pertains to Roman character set fonts only. For non-Roman
character set fonts, different rules apply. There should be a 'fond' to
go along with each language 'cmap', because other tables (width, kerning)
do not necessarily apply across different languages.
Roman legibility criteria
All Roman text fonts should be instructed for proper display and legibility
down to 9ppem. All Roman display and other special fonts should be instructed
for proper display down to 14ppem and be legible down to 9ppem. 'Proper
display' is defined as the style of the face being maintained and distinct
from other typefaces. For these purposes, 'text' fonts can be defined as
type used in body text; 'display' fonts are those special or decorative
styles used in headlines, titles, etc., that would not normally be used
in large blocks of small type.
These are the basic size requirements for instructing Roman fonts for
Apple. There is absolutely no reason not to meet legibility and display
requirements at smaller sizes if possible, once these requirements have
been met. In addition, if a display font can be instructed for proper display
down to a smaller size, so much the better. There is nothing wrong with
going beyond these minimum quality requirements, and better quality is
encouraged.
CJK (Chinese/Japanese/Korean) legibility criteria
CJK text fonts should be instructed for proper display down to 18ppem,
and display faces should also be instructed for use down to 24ppem. At
smaller sizes the legibility of the font is more important than the style
of the font. The reduction of strokes at small sizes is necessary, but
should be done in a consistent, regular manner. The 25- 40ppem range must
receive particular attention, because it is at these sizes that the instructions
are most important. Above 40ppem the glyphs are large enough to gridfit
with nominal instructing, and below 25ppem bitmaps are usually used.
Bitmaps should be included for 9, 10, 12, 14 and 18ppem if the font
has not been instructed down to these sizes. Whenever possible, the font
should be instructed as to as small a size as possible, and reliance upon
bitmaps should only be used when instructing is not feasible.
Other language legibility criteria
Fonts for other languages (scripts) should be judged by the Roman font
standards.
Instructing for screen
Bitmap evaluation
When evaluating glyphs at small sizes and low resolutions, it is important
to balance the design intent of the font with the limitations of the number
of pixels available to display design characteristics. It will be necessary
at small sizes and low resolutions to homogenize the characteristics of
the font to maintain legibility. One of the more difficult aspects of low-resolution
font design is that many design subtleties must often be sacrificed or
compromised at small sizes.
In general, the important features to look for while evaluating bitmaps
are as follows: consistency of heights (which may include keeping overhangs
from turning on at too small a point size, causing an exaggerated overhang),
consistency of stem thicknesses (and homogenizing horizontal and vertical
stem thickness differences), exaggerated or eliminated serifs, and curve
smoothness, with minimal stairstepping or jaggies.
In addition, at small sizes the stems for the uppercase, lowercase,
and figures may have to be homogenized so that the color of the font appears
correct. Only when the resolution of the screen or the size of the glyphs
get large enough to permit subtle differences to show up properly should
these differences be visible.
There should be no dropouts, which most often occur at the thin points
on curves or in diagonals. Similarly, there should be no blobs or stray
pixels. Use of diagonal controls will help prevent diagonals from pinching
off and losing pixels.
Smoothness
One of the characteristics of a font that takes up a large portion of
a reviewer's time is checking for 'smoothness.' This is the lack of bumps
and flat spots, and smooth transitions. It is not enough to impart these
qualities in the original artwork; it is necessary that they translate
as well as possible to rendered bitmaps. While bumps and flat spots can
sometimes be traced back to the original high resolution design, they are
usually caused by incorrect gridfitting or improper instructing. Often,
the only way to flatten a bump is with a delta, especially if it only occurs
at one or few sizes. Flat spots on a curve may require evaluating the instructing
of that curve to see whether it is grid fitting appropriately. This is
an area that absolutely requires the eye of a trained typographer.
Minor adjustments (deltas)
While deltas are the most often used method for controlling small problems,
especially those that only occur at specific sizes and resolutions, it
is recommended that other instructions be used when possible, because deltas
will not work under transformations or rotations. In addition, the typographer
can wind up using a large number of deltas to try to control one feature
at a number of different sizes, but still wind up missing some sizes. Usually,
a more general solution to a glyph's problem will hold up better.
Preprogram and CVT (Control Value Table)
It is strongly recommended that the Preprogram and CVT table be commented
often and with as much detail as necessary, for maintainability of the
font. Having comments and notes significantly decreases the amount of time
it takes locating a problem or navigating through the font. For those designers
who are familiar with programming, think of the Preprogram and CVT tables
as computer programs (which in fact they are) and comment accordingly.
Defining every value in the CVT table is not excessive.
Use separate CVT entries for different glyph parts and for different
axes, even if their values are the same, unless the glyph part being controlled
is intended to always be exactly the same in height and width, as in a
circle or square, for example. If separate CVTs are not used, it becomes
impossible to do subtle adjustments or revisions later on one part or axis
without affecting the other.
Assign CVTs keeping CVT cut-in values under consideration: if the CVT's
value differs too much from the actual distance between control points,
the CVT will be ignored.
[NOTE] Commenting is not possible in RoyalT, but generally
can be done when working with a high-level instruction font editor.
FDEFs (Function DEFinitions)
Use FDEFs whenever possible, wherever there is a series of instructions
that is repeated in many glyphs, analogous to a subroutine in a regular
computer program. This will considerably reduce the size of the font, is
faster, and requires less instructing.
FDEFs should be commented to describe their functions, like preprograms
and CVTs, when possible.
Methodical hinting
Hinting should be methodical. By not jumping around the glyph and instructing
piecemeal, but rather working from one point to another in a logical progression,
the need for explicitly setting reference points can be reduced. This in
turn reduces the instruction list, and the size of the font. Similarly,
not jumping back and forth between vectors, but instructing all x-axis
commands, and then all y-axis commands, for example, whenever possible,
will also cut down on extra instructions. Break instructions into logical
ppem sizes for conditional instructing and reducing deltas.
Engine compensation booleans
The black/gray/white boolean flags should be used correctly for future
compatibility. See the TrueType Font Format Specification for more details.
Squishing/expansion
Squishing occurs in QuickDraw when a glyph exceeds the ascent and descent
boundaries; QuickDraw senses this and reduces the height of the glyph by
a pixel, then rechecks and reduces again, as many times as necessary. Unfortunately,
it does not remove height in an intelligent way, and often doesn't reduce
the minimum amount necessary for the glyph to fit, leaving a glyph that
can be squished almost completely flat in some cases. If the typographer
sees this problem occurring, and reduces the glyph's height manually, in
a controlled and intentional way, this problem can be eliminated.
Glyphs should neither squish nor expand excessively; this is most likely
to occur at low resolutions, when fonts are run under QuickDraw. Because
this problem occurs at low resolutions, it is much more likely to occur
on screen, but will also occasionally occur in print at small sizes.
The glyphs most likely to squish are accented glyphs, where, in an effort
to maintain space between the base glyph and the accent, the designer has
pushed the accent outside the bounding box. If necessary, close up the
inter-contour space to bring the accent within the bounding box to prevent
or reduce squishing.
[NOTE] Being able to do this is one of the advantages
to using control points to position the compound glyph components, as the
attachment control point can be instructed to shift down in a controlled
manner.
Maintain inside contour white space
To maintain legibility, the designer should not allow glyphs to collapse,
but should maintain white space inside contours. When this cannot be done,
collapsing should be controlled and consistent throughout the font.
Controlling sidebearings
In addition to controlling the internal dimensions of a glyph, designers
must control the glyph's position within its unit value. This can be done
in several ways. For Roman fonts, the most common is to control from the
origin point to a point on the left side of the glyph. For languages that
read right-to-left, the typographer would want to control from the right
sidebearing to the right side of the glyph. Another method is to write
an FDEF that measures the distances between the origin point and the left
side of the glyph, and the right side of the glyph and the advance width
point, compare the two and shift the glyph if they differ by more than
a pixel.
This control is most critical at smaller point sizes, and can usually
be tapered off, allowing the glyph to position where it wants to, at around
24ppem, depending upon the font.
If the glyphs must pull to one side or the other, due to an odd number
of whitespace pixels, all glyphs should consistently pull with a bias to
one side or the other. If they are allowed to pull in any random direction,
the letter spacing will suffer, with some letter pairs having no space
between them, and some pairs having too much. For a left-to-right reading
font (e.g. Roman), it is better to let the glyph pull slightly left, if
it cannot be centered, allowing extra whitespace on the right. This allows
clearance for the cursor when editing text. For a right-to-left font (e.g.
Hebrew), the reverse is true; if the glyphs do not center exactly, the
pull bias should be to the right, allowing more space on the left.
[NOTE] Whatever method is used to control the positioning
of the glyph, the typographer will probably have more successful results
if s/he uses the side of the main body of the glyph (such as a main stem
or other major feature) as the reference, rather than a more extreme yet
minor feature on the glyph (such as a serif tip). See figure 3-6 for an
example.
fig. 3-6 Whitespace control using a main stem of the glyph instead
of a serif as the reference.
Scan control
Unfortunately, one of the tools most commonly used to prevent dropouts,
Scan Control, can cause stray pixels to appear, so it is best avoided if
at all possible. Scan Control also slows the font down considerably. If
it is used, it should be limited to small sizes. Generally, Scan Control
can be tested with waterfalls and adjusted so that it is active only up
to whatever point size would suffer from its absence.
Scan Control can be used both in the preprogram, where it will affect
the entire font, or in the instructions for individual glyphs.
[NOTE] When used in individual glyphs, scan control
characteristics do not get passed from a base glyph to its related component
glyph(s), so the scan control instruction must be replicated for both glyphs.
Care must be taken that if a change is made to the scan control instruction
for one, the other must be manually changed to match if similar scan control
characteristics are desired.
Arleigh Movitz
The Apple Fonts Group
