Liren Large Software Subsidy 15/15.iso/s/s076/2.img/TXT/TT1.TXT

Text File | 1992-04-21 | 31.0 KB | 590 lines

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=





TrueType Technical Talk #1:
An Introduction to Digital Typography using TrueType





George Moore,
November 5th 1991






Copyright 1991 Microsoft Corporation.  Permission is given to
redistribute freely for private non-profit use, provided this
notice remains with the document.
-----------------



In most digital type systems, whether implemented on a computer or
in a printer, there are just a few basic steps that the system
goes through in order to display characters on the target device.
The essential steps are:

    1. Load the font outline and feed it to the rasterizer.
    2. Scale the outline to the correct size.
    3. Fill the outline with pixels, creating a raster bitmap
    4. Transfer the raster bitmap to the display device.

Expanding upon this list gives us a more detailed look at how TrueType
works.  I'll list the steps in order, and then talk at length about
each one:

    1. Load the font and feed it to the rasterizer.
    2. Scale the outline to the correct point size for the correct
       resolution of the device.
    3. Apply the hints to the outline, distorting the contours to
       build what is known as a hinted, or gridfitted outline.
    4. Fill the gridfitted outline with pixels, creating a raster bitmap.
    5. Scan for dropouts (optional).
    6. Cache the raster bitmap.
    7. Transfer the raster bitmap to the appropriate display device.


Step #1: Loading the font
=========================
In a printer, the loading of a font is usually accomplished by the
printer's BIOS when it has to locate the font in ROM, or as a
downloaded version of the font stored in local printer RAM.  In a
computer, this is normally accomplished by the operating system when
it has to locate the font file on disk.  In Windows 3.1 in particular,
TrueType fonts are stored as .TTF files in the system directory of
your Windows directory.  These .TTF files are what is known in the
Macintosh world as the raw `sfnt' resources.  All TrueType fonts on
the PC are stored and used in Motorola format using big-Endian byte
ordering.  All Intel and other little-Endian implementations of the
TrueType rasterizer perform the byte swapping on the fly in order to
maintain binary compatibility with the Macintosh.  TrueType fonts can
be installed in the system by the user running the Control Panel, or
via an application using the new CreateScalableFontResource() in
conjunction with the AddFontResource() APIs.

When the user selects a TrueType font from a menu, Windows will go
out to the disk, locate the particular .TTF file and present it to the
TrueType rasterizer that is a part of GDI (the Graphical Device
Interface in Windows).  I will cover the font mapping, selection and
other Windows internals in a future posting since it is beyond the
scope of this document.


Step #2: Scaling the outline to the correct point size
======================================================
I need to give a little background and break this one large complex
step into smaller steps so that it can be better understood:

Outlines
--------
In a TrueType font, character shapes are described by their outlines.
A glyph outline consists of a series of connected contours and lines,
which are defined by a series of points that describe second order
(quadratic) B-splines.  The TrueType B-spline format uses two types
of points to define curves, those that are ON the curve and those that
are OFF the curve.  Any combination of off and on curve points is
acceptable when defining a curve.  Straight lines are defined by their
endpoints.

Generally, most professional font foundries like Monotype store their
digitized outlines in their internal libraries in a format known as
Ikarus.  Ikarus was developed by a company called URW in Germany and has
become the standard international interchange format for unhinted digital
fonts.  Monotype uses a tool called SplineLab from Projective Solutions
to convert the Ikarus data to a raw, unhinted, skeletal TrueType file.
Shrinkwrapped commercial end-user tools like Font Studio 2.0 from LetraSet
and Fontographer 3.5 from Altsys usually allow you to convert and
manipulate TrueType outlines from a number of different formats.

FUnits and the em square
------------------------
In a TrueType font file, the on and off curve point locations are
described in font units, or FUnits.  An FUnit is the smallest measurable
unit in the em square, which is an imaginary Cartesian coordinate square
in some arbitrary high resolution space that is used to size and align
glyphs.  The granularity of the em square is determined by the number
of FUnits per em, or more simply "units per em".  The greater the
number of units per em, the greater the precision available in
addressing locations within the em square.  And no, the em is not
short for "Auntie Em" of The Wizard of Oz, but instead is a historic
measurement in typography that refers to the space which will
completely contain the capital letter "M" of any given font design.
While this need not be strictly true in the world of digitized fonts,
it is still a reasonable rule of thumb.  Although all Apple and
Microsoft distributed TrueType fonts are built with an em square of
2048, the TrueType rasterizer actually allows you to build any
particular font with any arbitrary em square size up to 32767 (from
coordinate locations -16384,-16384 to +16383,+16383).  Outline scaling
will be fastest if the units per em is chosen to be a power of 2.

Scaling a glyph
---------------
The first step in this process is the conversion of FUnits to device
space, which will be dependent upon the physical resolution of the
target output device.

The Cartesian coordinate values in the em square can be converted to
values in the pixel coordinate system by the following formula:

   (FUnit value) * (point size of the letter) * (resolution)
  -----------------------------------------------------------
             (72 points per inch) * (units per em)

So, for example, let's say that you wanted to calculate the advance
width for the letter "p" in a particular font (the advance width is
how wide the character will be, including the space before and after
the letter).  This particular character will be at 18 point on a VGA
resolution screen (96 dpi).  The advance width of the letter that is
defined in the device independent space is 1250 FUnits, and the units
per em is defined for this font as 2048:

         1250 * 18 * 96
        ---------------- = 14.65 pixels wide
            72 * 2048

At 300 dpi, the same letter will be the same physical size, but because
the pixels are smaller it will take 45.78 pixels to represent the same
character.  At 1200 dpi it would take 183.11 pixels.  The computed
x-resolution size is used for metrics like the widths of characters,
while the y-resolution is used for ascender, descender and linegap
values.

In reality, scaling is actually performed by using the above formula
in conjunction with a standard 2x2 transformation matrix.  The
transformation can be computed as:

      Sx(Cos theta)      -Sy(Sin theta)
      Sx(Sin theta)       Sy(Cos theta)

"Sx" is the scale factor formula from above with the "resolution" value
set to the x-resolution of the target device.  "Sy" is the y-resolution,
and "theta" is the rotation angle in counter-clockwise degrees from the
vertical.  This formula handles all rotations, shearing, and stretching
of the outlines.  Applications under Windows 3.1 can directly
manipulate this transformation matrix with the GetGlyphOutline() API.

An em square size of 2048 may not sound particularly high, but it
provides an effective resolution much higher than the actual resolution
of the high-end 2500 dpi phototypesetters that are on the market today.
If you do the math, you will realize that a motion of 5.89 FUnits in
the em square space actually corresponds to motion of just 1 pixel at
2500 dpi at 10 point.  Which means that if you were using 10 point text
with an em square of 2048, your phototypesetter would need to have an
actual resolution of around 15000 dpi (or 225 million dots per square
inch) before the granularity of the em square outline would start to
have an effect on the number of pixels turned on or off on the actual
physical outline.  15000 dpi phototypesetters are not likely to come
on the market in the next couple of years.

When you display type on a particular physical device at a specific
point size, you gain an effective resolution measured in pixels per em
(ppem).  The formula for calculating pixels per em is:

                                 dots per inch
        ppem = point size * -----------------------
                             72 points to an inch

It is important to realize that the raster bitmap patterns formed
for a glyph at any particular resolution will be the same regardless
of how big those pixels are (assuming there is no optical scaling going
on, which I'll discuss later).  This seems like an obvious thing to say,
but it's something that a lot of people don't realize until you stop
to think about it.  This is why the ppem value is important.  Let's
say that you are looking at a 30 point glyph on a 96dpi screen.  The
ppem value for that glyph will be 30*96/72 or 40 ppem.  The 40 ppem
bitmap pattern of the character at 30 points on a 96dpi device will be
*exactly the same* as the 10 point version of the same character on a
300 dpi device.  This is because 9.6*300/72 equals 40 ppem, and 9.6
point rounds to 10 point (if that particular font tells the rasterizer
to round values to the nearest pixel, that is.  Otherwise it would be
9 point).  The pixels may be smaller, but they form the same raster
pattern.

This fact is important in both hinting of glyphs and caching of
bitmaps, both of which are covered later.  The important point to
remember in Step #2 is the fact that scaling an outline involves
converting the high resolution device independent outline into an
outline targeted for a particular display device.


Step #3: Applying the hints
===========================
In an imperfect world like the one we live in, there is always theory
and reality, and reality very rarely lives up to the theories.  The
theory in this case is the device independent outlines that are stored
in a TrueType font; the reality is that most low resolution devices
cannot do them justice.  Compromises always occur, usually in the
form of poor fitting of the outline to the pixels on the output device.
This is where hinting comes in.  Hints are used to produce legible
characters from the high resolution outlines on low resolution physical
devices below 800 dpi (depending upon the size of the character).  To
see why this happens, examine the following drawing of a capital letter
sans serif "H" outline (I couldn't figure out how to draw nice serifs
using just ASCII characters).  The dots represent the centers of the
pixels which form the grid of the output device:
.   .   .   .   .   .   .   .   .   .   .   .   .
       +-----+                   +-----+
.   .  |.   .|  .   .   .   .   .|  .  |.   .   .
       |     |                   |     |
.   .  |.   .|  .   .   .   .   .|  .  |.   .   .
       |     |                   |     |
.   .  |.   .|  .   .   .   .   .|  .  |.   .   .
       |     +-------------------+     |
.   .  |.   .   .   .   .   .   .   .  |.   .   .
       |     +-------------------+     |
.   .  |.   .|  .   .   .   .   .|  .  |.   .   .
       |     |                   |     |
.   .  |.   .|  .   .   .   .   .|  .  |.   .   .
       |     |                   |     |
.   .  |.   .|  .   .   .   .   .|  .  |.   .   .
       |     |                   |     |
.   .  |.   .|  .   .   .   .   .|  .  |.   .   .
       +-----+                   +-----+
.   .   .   .   .   .   .   .   .   .   .   .   .
Most every outline scaling system will use a simple method to
determine which pixels to turn on or off: if the center of the pixel
falls inside the outline, turn it on, otherwise turn it off.  You will
notice that the left vertical stem of the "H" encompasses the centers
of a two pixel column, meaning it will be two pixels wide.  However,
the right vertical stem only incorporates one pixel center column,
meaning the left stem will be twice as wide as the right stem, EVEN
THOUGH BOTH STEMS ARE EXACTLY THE SAME WIDTH IN THE ORIGINAL OUTLINE
(you can count the widths yourself to verify).  You may not actually
notice details like that when you are reading the text on the screen,
instead you'll just think to yourself: "Hey, that's a pretty ugly font."
The human eye is very good at picking out subtle abnormalities
like that.

Hints are used to distort an outline in a systematic fashion so as to
produce legible text.  In this case, the typographer might tell the
hinting mechanism to move the two stems slightly closer together:
.   .   .   .   .   .   .   .   .   .   .   .   .
         +-----+                 +-----+
.   .   .|  .  |.   .   .   .   .|  .  |.   .   .
         |     |                 |     |
.   .   .|  .  |.   .   .   .   .|  .  |.   .   .
         |     |                 |     |
.   .   .|  .  |.   .   .   .   .|  .  |.   .   .
         |     +-----------------+     |
.   .   .|  .   .   .   .   .   .   .  |.   .   .
         |     +-----------------+     |
.   .   .|  .  |.   .   .   .   .|  .  |.   .   .
         |     |                 |     |
.   .   .|  .  |.   .   .   .   .|  .  |.   .   .
         |     |                 |     |
.   .   .|  .  |.   .   .   .   .|  .  |.   .   .
         |     |                 |     |
.   .   .|  .  |.   .   .   .   .|  .  |.   .   .
         +-----+                 +-----+
.   .   .   .   .   .   .   .   .   .   .   .   .
This way both vertical stems and the horizontal stroke will all be
exactly one pixel wide.  The higher the resolution of the device, the
less you need hints because you have more pixels to play with.  If you
assume the above example was on a 96 dpi screen, at 300 dpi you would
have a little more than 3 times the grid density, and so an off-by-one
pixel error at 300 dpi would only be 1/3 the size of the same off-by-one
pixel at 96 dpi.  However, even at 300 dpi, hints are very important
until you start to reach 100 ppem.

The distortion of the outlines by the hints is accomplished in the
TrueType rasterizer by the execution of a rich set of instructions
which allow designers to specify how character features should be
rendered.  These instructions form an assembly language for font
hinting.  Within the TrueType rasterizer is a software-based interpreter,
much like the hardware-based CPU in a computer.  The interpreter
processes a stream of ordered binary instructions which take their
arguments from the interpreter stack and place the results back on
that stack.  All opcodes are 1 byte in size, but the data can be
either a single or double byte (word) depending upon the instruction.

A small example of some TrueType code follows.  This example is a
subsection of the hints used for the letter "B" in Times New Roman:

    SVTCA[X]
    SRP1[], 44
    SRP2[], 4
    SLOOP[], 3
    IP[], 51, 36, 0
    CALL[], 16, 31, 27, 22, 33, 35     /* Backward Serif 22->21->16 */
    CALL[], 15, 31, 27, 9, 33, 34      /* Forward Serif 9->10->15 */
    IUP[X]
    IUP[Y]
    RS[], 8
    JROF[], #LRnd0, *
    SRP0[], 0
    ALIGNRP[], 1

The TrueType instruction set is fully programmable, with loops,
conditionals, branching, math operations, etc.  As you can see from
the example, in this particular case Monotype has defined a subroutine
which contains all of the hints necessary to manipulate the serifs of
Times New Roman (the "CALL[]" statements).  Besides the good programming
practice of saving code space, this also means that you will be
guaranteed that all of the serifs in a particular font will be rendered
identically at any given point size, thus preserving beauty and harmony
within a typeface.  Since most of the complex problems associated with
the execution of the hints can be resolved at compile-time, this allows
the small, fast, dumb rasterizer to execute the code very quickly at
run-time.

The executable portion of the TrueType code is broken into three main
sections (ranked from least to most specific):

    1. The code that is executed when the font is first loaded,
       called the font program.  This is stored in the 'fpgm'
       table in the font file.  In the Monotype-produced fonts
       for Windows 3.1, the fpgm is generally used for subroutine
       definitions.
    2. The code that is executed any time there is a point size
       change, transformation change, device resolution change, or
       spot size change.  This is called the control value program
       and is stored in the 'prep' table.
    3. The code that is attached to individual glyphs which is
       stored in the 'glyf' table.

This offers great flexibility in scope of certain operations which can
be triggered by specific events within the rasterizer.  The code to
manipulate the font-wide serif subroutines would probably go in the
font program ('fpgm') and actually be called in the individual glyph
program.  However, the code which makes sure the center of the "e"
doesn't close up at small point sizes would only go in the glyph
program.  Since the code can be localized to specific events, another
interesting thing that can be done is use similar subroutines stored
in the font program for all members of a typeface family (light, regular,
demibold, bold, heavy, black, etc.) which would maintain similar visual
consistency across the entire family.

The control value program mentioned in section #2 above is run to set
up values in the control value table (known as the CVT) which allows
for common control values to be applied across all of the glyphs in a
font.  For example, you might want all of the glyphs in a font to jump
from a stem width of two pixels at 17 point to three pixels at 18
point, again for visual consistency.  This can be easily accomplished
by plugging the right values into the CVT in conjunction with the Move
Indirect Relative Point (MIRP) opcode.  The CVT is also useful for
passing information between the various elements in a special kind of
glyph, known as a composite glyph, which can be built up from several
different elements within a font.  A good example of composite glyphs
are the accented characters located above ANSI 0x7F, such as "A acute".
In the case of "A acute", you can simply take the glyph of the "A" and
merge it with the "acute" accent to form a completely new glyph that is
actually comprised of two different elements.  This saves both code space
and hinting time.  Composite glyphs can also be used in conjunction with
any transformation to save a lot of space within a font.  For example,
if the font design allowed it, you could create the comma, open single
quote, close single quote, open double quote, close double quote and
baseline double quotes all by various transformations of a single font
element which need only be hinted once.

If you change the size of the character, the resolution of the device,
or the transformation of the outline (by rotation, skewing, etc.), you
have to re-execute the hints for that specific raster bitmap pattern.
In the Microsoft and Apple distributed TrueType system fonts, hints are
turned off during any non-standard outline transformation.  Only for
rotations of orthogonal angles (90, 180 and 270 degrees) are hints
used since the alignment of the outline to the grid will be the same
in those cases.  There *are* hinting algorithms which could be executed
in TrueType which are rotation invariant, however we do not make use
of them.  Most other digital font formats do not provide hints under
rotation either (however, some versions of the Intellifont rasterizer
leave hints on under rotation so that they can use the "black distance"
information to embolden the font if a bold version is not available).
It is easy to turn off the execution of hints under rotation with
the INSTRCTRL[] opcode.

Writing raw TrueType instructions can be a very time consuming and
error-prone chore, just like writing in any form of assembly language.
It is also not a good idea to make typographers, who are artists, learn
a computer science approach to doing their job.  This is where the
availability of good tools comes in.  There can be many approaches to
hinting fonts, but the method that Monotype has been using for our base
Windows fonts has been with the use of a high-end tool called "TypeMan"
from a company named Type Solutions.  TypeMan will first make a
best-guess for the hinting of the font by running its own autohinter on
the glyphs first.  It then allows you to tweak the generated code it
produced in a high-level language format which will then be compiled
down into raw TrueType instructions.  Like any good compiler, it checks
syntax, resolves "linking" problems in addition to doing quite a few
other housekeeping duties within the fonts.  Type Solutions can be
reached at [phone] for information about this and other tools.

Using TypeMan is one approach to generating TrueType fonts.  Another
is conversion of existing fonts to TrueType format.  The TrueType
instruction set is a superset of all known hinting methods, so
it is theoretically possible to convert any other hints to TrueType
hints.  In fact, it's more than a theory -- this is exactly how
several font foundries are producing their initial set of TrueType
fonts.  They simply take their existing hinted fonts and recompile
them in TrueType format.  This allows a very large library of fonts
to be created rather quickly.  And since the hints are being
transferred directly, there is no degradation of the quality of the
resulting bitmaps.

Other companies, like Bitstream and AGFA/Compugraphic, will take their
existing fonts, convert their own hints to TrueType hints, and then go
back and do extra work on the font.  They have developed a production
environment that allows them to take their existing library of outline
fonts and add the appropriate hinting and font file structure needed
to support new font technologies.

TrueType is the only digital type system available on the PC or the
Macintosh which provides this arbitrary, user-defined, flexible,
algorithmic approach as a hinting mechanism.  This works well for
many different languages, since the hinting algorithms you would use
for Latin fonts will be different than for Kanji, Chinese, Korean,
Arabic, Hebrew, Devanagari, Telugu, Kannada, Sinhalese, Bengali,
Gurmukhi, etc.


Step #4: Fill the outline, creating a raster bitmap
===================================================
In order to first fill an outline with pixels efficiently, it is
desirable to decompose the curves into scanlines so as to create an
edge list (some people call it an edge table).  This list contains all
of the edges of the contours sorted by their smaller y-coordinates so
that the filling algorithm does not have to calculate intersections
with the outlines at every single pixel location.  More information
on this process can generally be found in any introductory computer
graphics textbook and it is not worth going into detail here.

This is a very quick step since all of the hard work has already been
done.  The outline has already been distorted to correspond to the
size of the pixels (step #3), and the system already knows where the
edges of the outlines with respect to the grid are located (step #4a).
All the filling algorithm has to do at this point is decide if the
center of each pixel is enclosed within the outline.  If it is, you
simply turn that pixel on, otherwise leave it off.


Step #5: Scan for dropouts
==========================
"Tune in, turn on, and drop-out" was the motto for millions of
people during the 1960's, although it could very well be applied to
portions of digital typography today.  Tuning the outline for the
grid, turning pixels on and checking for dropouts are three of
the major components of any font scaling system.

A pixel dropout occurs whenever there is a connected region of a
glyph interior that contains two black pixels that cannot be connected
by a straight line that only passes through those black pixels.  In the
following close-up example you can see that the outline for the center-
bar of the letter "H" happens to go between two rows of pixels:
.     .    |.     . |   .     .     .     .   | .     .|    .     .
           |        |                         |        |
           |        |                         |        |
           |        |                         |        |
.     .    |.     . |   .     .     .     .   | .     .|    .     .
           |        +-------------------------+        |
           |                                           |
           |        +-------------------------+        |
.     .    |.     . |   .     .     .     .   | .     .|    .     .
           |        |                         |        |
           |        |                         |        |
           |        |                         |        |
.     .    |.     . |   .     .     .     .   | .     .|    .     .
This is one example of a dropout (although this one could be corrected
with some appropriate hints).  Another more difficult one to fix (and
more difficult to illustrate in ASCII) could happen on a thin curve that
just happened to pass between two pixel centers.

It is possible to test for potential dropouts by looking at an
imaginary line segment connecting two adjacent pixel centers.  If this
line segment is intersected by both a on-Transition contour and an
off-Transition contour, a potential dropout condition exists.  The
potential dropout only becomes an actual dropout if the two contour
lines continue on in both directions to cut other line segments
between adjacent pixel centers.  If the two contours join together
immediately after crossing a scan line (forming a stub), a dropout
does not occur, although a stem of the glyph may become shorter than
desired.

Depending upon the glyph shapes, dropout control can be a time-expensive
operation.  For this reason it is an optional step that can be turned
on or off by the TrueType SCANCTRL[] opcode.  It is worth noting that
you can turn SCANCTRL[] on or off on a per character basis depending
upon the size of the glyph (its ppem value).  For example, a character
like the letter "I" will generally not have dropouts even at low ppem
values, so you can speed up its rasterization by turning SCANCTRL[] off.
However, the character "@" is very difficult to image because of all
the delicate curves involved, so you might want to leave SCANCTRL[] on
for even large sizes (in some of the fonts that we ship in Windows 3.1,
SCANCTRL[] for the "@" symbol is left on up to 60 ppem).  It is up to
the individual font vendor to weigh the tradeoffs involved with dropout
control.  For example, a vendor selling barcode fonts probably wouldn't
need it at all.


Step #6: Cache the raster bitmap
================================
Steps #6 and #7 are not so much a part of the rasterizer, but more
a part of the environment that the rasterizer is implemented in.

For most Latin fonts of only a couple hundred characters each, a cache
of any reasonable size makes the speed of the rasterizer almost
meaningless.  This is because the rasterizer only runs once, the
first time you select a font or a new point size, and from then on
the bitmaps are transferred out of the cache to the screen or page
buffer.  If you are editing a document with a particular font, chances
are that 99.9% of the time the font is used on the screen it is being
transferred from the cache.

In Windows 3.1, all TrueType bitmaps at all ppem values are cached
automatically in the kernel's private memory arena.  And since the
Windows kernel will make use of all unused memory in the system as its
cache, this means you could have a font cache of several megabytes.  If
you are running in protect mode on the 80386, Windows will also page
bitmap caches to the swap file when physical memory is filled.  This
means you could have, for example, 32 megabytes of virtual font cache
on an 8 megabyte machine.  With the advent of the new virtual disk
driver in Windows 3.1 running in protect mode (called "fastdisk"), it
is faster to load cached bitmaps from disk than to re-render the
character from scratch.  The kernel uses an LRU system to discard old
data when memory fills up, or when an application asks for extra
memory in low memory conditions.  But generally speaking, not much
is ever flushed from the cache since most swap partitions are so large
in relation to the data that is being cached.  This is in stark
contrast to third-party font scaling solutions which use a smaller
fixed cache which cannot be dynamically allocated to other programs.
These take memory away from applications in low memory conditions and
do not make the best use of free memory when it is available.

The caching keys used by GDI in the selection of the pre-rendered
raster bitmaps are specific to the transformations applied to the glyph
and to the effects of optical scaling (which is a venerable typographic
concept which allows for changes in the shapes of the glyphs depending
upon not only the ppem value, but also the pointsize).


Step #7: Transfer the raster bitmap from the cache to the display
=================================================================
This step is also implementation specific.  Most printers have a
dedicated blitting chip which can quickly blast bitmaps from the local
printer cache to the page buffer.

Under Windows 3.1, it really depends upon what kind of hardware you
have in your machine as to how this step is accomplished.  If you have
a video card which contains a hardware blitter (which is generally a
swell thing to have under Windows anyway), the font bitmaps can be
quickly moved from the cache via a direct DMA transfer.  If you have a
normal video subsystem in your PC, Windows will handle the transfer of
the bitmap via software, which is still reasonably quick.

Of probable equal importance to the transfer of the bitmaps to the
screen is the communication of the metrics information in the font to
the applications in the system.  The new TrueType APIs will return
many useful values, such as left and right sidebearing values for
individual characters, x-height of the font, em square size, subscript
and superscript size values, underline position, strikeout position,
typographic ascent, typographic descent, typographic linegap, the
italic angle of the font (useful for making an insertion cursor match
the angle of the font), and many other interesting things.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=