(Far from being an expert on fonts, but commenting anyway... ;)
Peter B. West wrote:
I have read again the Wiki page on the font subsystem in the light of my current work with Java fonts. I'm afraid that I am still convinced that font handling is properly the preserve of the renderers. The layout engine needs only the font metrics, even for Java-based layout. As far as layout is concerned, the glyphs could all be Wingdings, as long as the metrics are right. The other required information is that relating to font selection, as discussed above. The logical home for font selection information is the renderer.
I see no problem with this. Ideally, anything renderer-specific, including fonts, should be in the appropriate fop.render.{rendertype} package.
This is not to say that, once a clean fonts interface has been developed and implemented in all of the renderers, a further level of abstraction cannot be applied to bring all of the information under one umbrella. However, consider the problem of creating a new renderer. Fonts are inherently renderer specific. It may be that those fonts are shared between more that one renderer, but that fact is incidental to, e.g., the common ancestry of PS and PDF.
If any render type relies on the fonts of another render type (e.g. PS using PDF), we can have it import or subclass the font libraries of that render type. (E.g. render.ps.xxxx code would import, say, render.pdf.font.xxx classes.) The dependencies are better self-documenting that way, IMO.
This seems to be the pivot around which both approaches can coalesce. As I look at this for longer, I see that my initial notions about the requirement for fonts are compatible with the generics that Jeremias and Victor are working towards. Those are, it seems to me, a set of handlers for different types of Fonts - Type 1, TrueType, OpenType, Metafont, Framemaker fonts, whatever.
Which is more sensible - writing a renderer's font handling to a common renderer font interface as an integral part of the renderer implementation, or discovering the fonts quirks of this particular renderer and adding them separately to a central font handler/registry?
The latter is outside my scope of knowledge (but sounds messy ;)--as for the former, what font-specific methods (and their signatures) do you see us needing to add to our render.Render interface (which declares the minimal methods needed by layout to interact with a renderer)? getFontMetrics()? isFontSupported()? (Currently, there is just a setupFontInfo() in this interface, which, as you say, seems nonideal--layout feeding the renderers the FontInfo.)
At the moment, I don't see any font-specific methods required. The basic methods are
FopFont getFont(String family, <enum> style, <enum> variant, <enum> weight, <enum> stretch, float size, <enum> selectionStrategy);
FopFont getGenericFont(<enum> type. <enum> style, <enum> variant, <enum> weight, <enum> stretch, float size);
FopFont getSystemFont(<enum> type);
where <enum> is probably an int in all cases. selectionStrategy determines whether, e.g., intelligent font substitution occurs if the family doesn't have an exact match.
Individual renderers would access their own databases of available fonts, and make their own decisions about what comprises a generic font, what comprises a system font, and how to build virtual fonts if necessary. This functionality within the renderers could be built on top of the Type1, TrueType, etc. versions of FopFont. However, individual renderers may need to vary the outcomes. For example, PDF, although it uses Type1 and TrueType fonts, needs to express them somewhat differently. Consider that a throw-away comment; I don't know how PDF uses these font types.
Take the Java renderer. By including "appendedfontpath" in a new or modified font.properties file, I can add new Type 1 or TrueType fonts to the JVM. Let's say I find a Garamond font when I start up. Does it qualify as a serif font? As a fantasy font? That sort of information can be built into the relevant underlying font handler, but I can see that individual renderers might want to override some methods in order to make their own Quality Of Service decisions. See the Note under "auto" in 7.8.3 "font-selection-strategy" in the 1.1 Draft.
What I have said qualifies as a "central font registry" in a loose sense, which may be refined later. E.g., QoS information may progressively be moved into the underlying font type handlers. However, it seems to me that the final decision is with the renderer, and it is the renderer that should be queried when the FO tree is being built and fonts resolved.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
