FOray Modules: FOrayFont

Contents

• General Design
• Hints
• Notes
• Developer Font Resources

General Design

Within the system, there is a strong distinction between these two concepts:

• font registration and selection
• font use

Everything starts with font registration. It records what is possible. It helps the FontServer select something usable from what is possible. It then creates the usable font structures that are made available to the client application. The following diagram illustrates the relationship between the font-configuration elements, the font registration classes and the font use classes:

Each row of the above table documents the complete family tree of its members. For example, a font-configuration <font> element can generate exactly one RegisteredFont instance, which in turn can generate up to one FreeStandingFont instance and up to one SystemFont instance. The same is also true going the other way. For example, and FreeStandingFont has exactly one RegisteredFont "parent", which in turn has exactly one font-configuration <font> "parent."

However, there is also a vertical heritage concept in the table above. Within a column, a <font> element may have zero, one, or more child <font-description> elements. In other words, multiple <font-description> elements can point to the same <font> element. This separation between a font and the way it is used is what allows the font to be used more than one way.

Note that because potentially both a FreeStandingFont and SystemFont can be encapsulated in a RegisteredFont that the user must tell the system which one to use. This is done primarily through methods in FontConsumer that tell the FontServer whether the client application can use the two types of fonts.

Hints

This section is a random collection of "gotchas" that we have come across that are worth considering from time to time, especially if you are working on a "how come?" issue.

• Many font concepts, especially (but not exclusively) for Type1 fonts, are based on PostScript concepts. This is true especially of filters and encodings. FOray has consolidated such items into the foray-ps module.
• Fonts often contain kerning pairs that include spaces. If the client application kerns "words", it may improperly exclude such kerning during line-breaking decisions and when generating output.

Notes

Some random fragments of documentation.

Single-byte fonts do not get re-encoded as a result of subsetting, but composite fonts do. Therefore the information stored for each differs. Composite fonts must keep track of the mapping between the original index and the subset index. Single-byte fonts only need to keep track of which chars/glyphs are used.

XSL-FO does not have a mechanism for directly choosing the font to be used in a document segment, but rather provides a mechanism for describing the font selection. One implication of this is that the document may need to be broken into smaller logical units than would otherwise be necessary, if more than one font is needed to cover the characters in a particular segment. The FO Tree has text nodes (FOText nodes in FOray) as leaves, that is, they have no possibility of having children. However, there is an implication of children if the text must be broken into smaller pieces to track the differences in selected font. The following solutions to this problem were considered:

• Create an FOTree concept that is a child of FOText. This is probably too complex, partly because we wish to keep the original text intact and just decorate it for output purposes.
• Handle during layout. This is also complex.
• Handle at render-time. This is not always feasible. And in FOray's design, an Area computes its size based on the font, so this does not work at all.

Developer Font Resources

• Adobe's Type Technology page contains links to many important type-related documents.
• Links to TrueType specification fragments can be found at the Microsoft Typography Specifications Overview page.
• OpenType specification
• The article "How does Macintosh Store PostScript Fonts?".