FOrayFont: Planning

Contents

• Introduction
• Agenda, Limitations, To-Do List
• Configuration File Format

Introduction

All of the items on this page are for planning purposes, and, unless indicating otherwise, are not related to current releases of FOrayFont.

Agenda, Limitations, To-Do List

FOrayFont’s goal is to provide metrics and embedding (including subsets) support for both simple and complex versions of the following font formats, when used as free-standing fonts (i.e. for applications that have direct access to the appropriate font and metrics files, and are not depending on operating system registration):

• Device fonts (printer fonts, bitmapped fonts, etc.)
• Postscript Type1 fonts (PFA, PFB, and Mac file formats)
• TrueType fonts (both PC and Mac file formats)
• OpenType fonts (both TTF and CFF formats)

using the following font metrics file formats:

• PFM
• AFM

with sufficient information to properly support the following output formats:

• PDF
• PostScript

Here is a record of the progress made, and the tasks remaining:

Configuration File Format

The following attributes should be added to the font-description element:

• size = length (example “9pt”). Required only for bitmap fonts. Implies that a metrics file is necessary. Note that this does not correspond to the XSL-FO font-size property.
• variant = normal | small-caps | both. Corresponds to the XSL-FO font-variant property. Note however the “both” option. Some OpenType fonts contain glyphs for both the normal and small-caps variant, and use a Glyph Substitution Table to map between the two. So, even though one cannot select “both” when resolving a font, a font could contain both. Optional (default “normal”).
• stretch = ultra-condensed | extra-condensed | condensed | semi-condensed | normal | semi-expanded | expanded | extra-expanded | ultra-expanded. Corresponds to the XSL-FO font-stretch property. Optional (default “normal”).

Note that style, variant, and stretch can all be simulated using other means. Rather than embedding this information in the font configuration file, we should probably have the client application tell us through some other means which of these are permissible, and return an object that wraps the font object along with instructions about how to use that font to accomplish the desired result. For example, if the user requests XYZ font with small-caps at 12 pts, if a small-caps variant is not available for that typeface, then we should return the regular font with instructions to convert lowercase letters to uppercase and to present them at 9.6 pts (for example).

This raises the issue of allowing the user to describe some sort of precedence in the font resolution process. For example, if small-caps is not available in a high-priority font-family, but is available in a lower-priority font-family, we need to know whether it should be simulated in the high-priority font-family instead of being used in the low-priority family. Again, this information is not specific to the fonts themselves, and might vary from one document to another, or even from one application to another, and should therefore probably be passed to forayFont through some other means, presumably by setting variables accessible through the FontConsumer.

The configuration file should provide a way for a FreeStanding font to be associated with a System font: The presence of attribute "system-name" for element "font" means that use of this font will create a FOray SystemFont, not a FreeStandingFont. The font-file attribute will be required in this case, and the font-file will be used in the instantiation of the java.awt.Font underlying the SystemFont. If the "embed" attribute is included, the underlying font-file will be used to embed the font in the output document.