AAT Font Quality Specification
(AAT) BITMAPS
Overview
Intended mainly for CJK fonts, bitmaps are now put into tables inside
of the 'sfnt'. Embedded fonts of this type are called "sbits",
to distinguish them from other forms of embedded fonts. The sbits are comprised
of two tables, the 'bloc' (bitmap location) and 'bdat' (bitmap data) tables.
These are analogous to the 'loca' and 'glyf' tables.
These tables support various formats and sizes of bitmap fonts. Discontiguous
ranges are supported, but a large number of ranges for a specific point
size could affect performance. Bitmap representation for a glyph at every
point size is not required. The only glyph that must be included at every
point size is the missing char glyph. A good use of ranges are in CJK fonts.
The first few hundred proportional glyphs would be in one range and the
rest of the thousands of glyphs would be in another range and potentially
in a different format.
Sbit data can be thought of as the ultimate size-and-resolution specific
instruction. If a font cannot be made to accurately represent glyphs at
smaller point sizes with a resolution of 72dpi, precise bitmaps for those
glyphs can be embedded into the font.
The various formats in which the bitmaps are stored are designed for
portability, speed, and compactness. The tools used by the typographer
should be able to decide which of the formats are best for a particular
situation, allowing the user to override if so desired.
With the addition of these tables, it is possible to have an sbit-only
font that has no scalable glyph data. While this is strongly discouraged,
sometimes it may be unavoidable.
 |
[NOTE] A limitation of bitmaps is that they are
designed to be sized and shaped correctly for only one fixed resolution
(72dpi). If, in the future, screen resolutions change or improve, then
these bitmaps will not work properly. |
(These bitmaps can be designed for any resolution, and the x-ppem does
not have to be the same as the y-ppem. Newton is using these formats for
multi- depth bitmaps for different screen depths. The designer could even
do antialiased and color fonts. A color reference field is included in
the specification.)
Matching bitmap widths with 'hdmx' tables
Currently the bitmaps use whatever metrics are embedded within the sbit.
The tools creating the sbit data should in the future be able to get the
metric information from the 'sfnt'. This guarantees that the data will
be the same, and will improve performance.
It is suggested that the fractional (unhinted) metrics be obtained from
the 'hhea' or 'vhea' table and the device (hinted) metrics be obtained
from the sbit data. Therefore, any tools that create sbit data should store
the device metrics.
Matching bitmap styling with scalable contours
When designing bitmaps, the typographer should attempt to keep the bitmaps
looking as close to the intended design of the scalable font as possible.
This will prevent the occurrence of a user changing font sizes and having
glyphs change their look. See also: Chapter
3: Bitmap evaluation.
Figure 5-1 shows a screen-grab of a waterfall displaying some of the
worst-case problems that can occur when bitmaps are not designed to match
the scalable font, in this case New York. (The bitmaps for New York were
designed seven years before the advent of TrueType, so discrepancies are
to be expected.) In this example, 9, 10, 12, 14, 18, 20 and 24pt bitmaps
are installed. All other sizes are TrueType (scaled). Note the following
problems:
fig. 5-1 Annotated waterfall showing improperly designed bitmaps (screen-grab).