Peter B. West wrote:
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.
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.
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.)