FOray Users
Module Users

FOrayFont: Planning



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:

Task Description Status
modularize (make into an independent package)
isolate font-related code Move font-related classes from fop-maint to foray-font, adjusting dependencies in fop-maint as needed. Completed 5-31-04. Tagged “ms_1” (Milestone 1) in repository.
refactor API
  • Make foray-font architecture service-oriented.
  • Lock-in API (future API changes to hopefully be backward-compatible)

The reformulation of the classes and API are not difficult, but applying the changes to fop-maint will be a chore, and relatively high-risk. We should be able to test PDF and PostScript, but will need others to test effects on the other interface points, like SVG and the AWT Renderer.

Completed 7-13-04. Tagged “rel_0_1a1” (Release 0.1 alpha 1) in repository. API is not locked. There are some minor API changes that will need to take place after the font configuration changes are made.
release No features or even bug-fixes in this release, but allows developers to start evaluating and testing the interface.  
bugs Most notably, the TTF encoding problem. Will research FOP’s bug-tracking system for others. TTF encoding problem fixed approx. Sep. 8, 2004. Included in 0.2.
font metrics Get metrics directly from the font or .pfm file. (Eliminate the current need to create and use a separate xml file for these). Completed c. Aug. 2, 2004. Included in 0.2.
support AFM for font metrics AFM contains some information (such as the FontBBox and StemV values) which are needed for PDF output, but are simply not in PFM files. Also, using AFM will give us a clean, standard way to allow users to 1) add metrics for fonts which have no physical font file to be parsed (such as device fonts and bitmapped fonts in general), and 2) compensate for poor metric information within other fonts.  
Support Type1 CID Fonts    
Support Type1 Fonts in Macintosh format    
Support TrueType Fonts in Macintosh format    
Handle subsetting for Type1 fonts    
Handle subsetting for simple TrueType fonts    
Basic OpenType support (TrueType outlines) Same level of support as for Type1 and TTF, i.e. metrics, embedding, etc.  
Basic OpenType support (PostScript/CFF outlines) Same level of support as for Type1 and TTF, i.e. metrics, embedding, etc.  
Font resolution work Handle font-selection-strategy properly. Need to read through FO tree looking for FOText objects that need to be broken into smaller pieces due to needing to switch to a different font to comply with font-selection-strategy. One possible solution is to add a Map to FOText that uses the FOText offset as the key, and the resolved Font object as the value.  
OTF Glyph Substitution  Support for ligatures, small-caps, old-style figures, etc. Will need to stop and work a bit on the FOTree before or while tackling this, as character context is important.  
OTF Glyph Positioning Support for combining diacriticals (e.g. Vietnamese), calligraphic writing systems (e.g. Urdu), etc. Also need character context for this work.  
PostScript support. To the extent possible, make all of the above features available for use in PostScript output.  
release As useful.  

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.