Peter B. West wrote:
I wrote:
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.
(Still learning...)
But wouldn't we need to add some form of isFontSupported(fontName, ...) to the Renderer interface? AFAICT, the XSL font-family property allows me to specify any font I want, so long as it is supported by the RenderType I chose. So if I invent a new RenderType, say Glen Document Format (GDF), and invent a new font for it, "Glen Font", isFontSupported("Glen Font") would return "true" for the -gdf output type and "false" for the -pdf output type. Then, layout would use that boolean value to determine whether it needs to fall back to a backup/default font.
That would be covered in the combination of getFont(...) and selectionStrategy. If the selection strategy excludes intelligent font substitution, and the given font family is not available, return null. If intelligent substitution is allowed, then let the renderer select another font family. It's worth reading the relevant parts of the Fonts section in the CSS2 spec for some insight into the recommended font selection strategy. XSL-FO adds another twist through font-selection-strategy.
The font-family property returns a list, the idea being that a series of family-names or generic-names can be tried in sequence to resolve a font. I'll have to read the CSS2 description again to determine exactly how .
Also, (this point I'm less certain on) a getFontMetrics(fontName) of some sort would be needed so layout can determine how much space "Mary had a Little Lamb" would consume using my new font on the defined output type, correct? getFontMetrics() could be centralized in one place instead of being renderer-specific, but if so we may need to handle the issue of multiple renderers possibly having the same name for a font type but different metrics/meanings for them. (E.g., "courier new" having different sizes in awt than it would in pdf, or a render type short-circuiting a popular font that it doesn't support to a similar supported one with slightly different metrics.)
The font metrics would be implicit in the Font (or FopFont) object returned from the renderer. Having the renderers (explicitly or implicitly) returning the Font object ensures that the layout's notion of metrics is the same as that of the renderer.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
