FreeType Glyph Conventions

Here an improved version of the algorithm:

Note that with fractional pixel positioning, the space between two given letters isn't fixed, but determined by the accumulation of previous rounding errors in glyph positioning.

3. Simple kerning

Adding kerning to the basic text rendering algorithm is easy: When a kerning pair is found, simply add the scaled kerning distance to the pen position before step 4. Of course, the distance should be rounded in the case of algorithm 1, though it doesn't need to for algorithm 2. This gives us:

Algorithm 1 with kerning:

Algorithm 2 with kerning:

4. Right-to-left layout

The process of laying out Arabic or Hebrew text is extremely similar. The only difference is that the pen position must be decremented before the glyph rendering (remember: the advance width is always positive, even for Arabic glyphs).

Right-to-left algorithm 1:

The changes to algorithm 2, as well as the inclusion of kerning are left as an exercise to the reader.

5. Vertical layouts

Laying out vertical text uses exactly the same processes, with the following significant differences:

• The baseline is vertical, and the vertical metrics must be used instead of the horizontal one.

• The left bearing is usually negative, but this doesn't change the fact that the glyph origin must be located on the baseline.

• The advance height is always positive, so the pen position must be decremented if one wants to write top to bottom (assuming the Y axis is oriented upwards).

Here the algorithm:

6. WYSIWYG text layouts

As you probably know, the acronym WYSIWYG stands for "What You See Is What You Get". Basically, this means that the output of a document on the screen should match "perfectly" its printed version. A true WYSIWYG system requires two things:

• device-independent text layout

  This means that the document's formatting is the same on the screen than on any printed output, including line breaks, justification, ligatures, fonts, position of inline images, etc.

• matching display and print character sizes

  The displayed size of a given character should match its dimensions when printed. For example, a text string which is exactly 1 inch tall when printed should also appear 1 inch tall on the screen (when using a scale of 100%).

It is clear that matching sizes cannot be possible if the computer has no knowledge of the physical resolutions of the display device(s) it is using. And of course, this is the most common case! That is not too unfortunate, however, because most users really don't care about this feature. Legibility is much more important.

When the Mac appeared, Apple decided to choose a resolution of 72 dpi to describe the Macintosh screen to the font sub-system (whatever the monitor used). This choice was most probably driven by the fact that, at this resolution, 1 point equals exactly 1 pixel. However, it neglected one crucial fact: As most users tend to choose a document character size between 10 and 14 points, the resultant displayed text was rather small and not too legible without scaling. Microsoft engineers took notice of this problem and chose a resolution of 96 dpi on Windows, which resulted in slightly larger, and more legible, displayed characters (for the same printed text size).

These distinct resolutions explain some differences when displaying text at the same character size on a Mac and a Windows machine. Moreover, it is not unusual to find some TrueType fonts with enhanced hinting (technical note: through delta-hinting) for the sizes of 10, 12, 14 and 16 points at 96 dpi.

The term device-independent text is, unfortunately, often abused. For example, many word processors, including MS Word, do not really use device-independent glyph positioning algorithms when laying out text. Rather, they use the target printer's resolution to compute hinted glyph metrics for the layout. Though it guarantees that the printed version is always the "nicest" it can be, especially for very low resolution printers (like dot-matrix), it has a very sad effect: Changing the printer can have dramatic effects on the whole document layout, especially if it makes strong use of justification, uses few page breaks, etc.

Because glyph metrics vary slightly when the resolution changes (due to hinting), line breaks can change enormously, when these differences accumulate over long runs of text. Try for example printing a very long document (with no page breaks) on a 300 dpi ink-jet printer, then the same one on a 3000 dpi laser printer: You will be extremely lucky if your final page count didn't change between the prints! Of course, we can still call this WYSIWYG, as long as the printer resolution is fixed.

Some applications, like Adobe Acrobat, which targeted device-independent placement from the start, do not suffer from this problem. There are two ways to achieve this: either use the scaled and unhinted glyph metrics when laying out text both in the rendering and printing processes, or simply use whatever metrics you want and store them with the text in order to get sure they are printed the same on all devices (the latter being probably the best solution, as it also enables font substitution without breaking text layouts).

Just like matching sizes, device-independent placement isn't necessarily a feature that most users want. However, it is pretty clear that for any kind of professional document processing work, it is a requirement.