(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.
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.)
Thanks, Glen
