Peter B. West wrote:
Although not mandated in XSL-FO, CSS2 offers a number of methods of font matching, only some of which preserve metrics. The FO User Agent is free to make implementation-specific decisions about this, I assume. My main interest here is in whether we want to try to separate out the font handling so that we try to guarantee identical layout on any renderer, or whether we state up front that such universality is *not* on offer.
I don't think the TXT renderer will in general render to the same layout as others :-) Nitpicks aside, fonts may be renderer specific. If different renderers use an identical font (e.g. a user configured TTF) chances are that the layout is the same, provided bitmap images are rendered identically. If different renderers use different fonts, which may have different metrics even if they are the same family, the layout is likely to be different too. I can't see how to avoid this.
This was my original perception. (I hadn't even thought about the different rendering of images.)
BTW fonts aren't the only considerations, others are color and the discretization of coordinates (e.g. bitmap vs. vector format).
All of which leads me to the question of what, exactly, we are trying to isolate and amalgamate in the font system. We can't get away from renderer dependencies, so the target renderer is going to have to be accommodated before any atomic elements are introduced to the Area Tree. As I said, I haven't been closely following the fonts discussion, but I'm confused as to where it fits in the scheme of things, and what it is trying to achieve.
...
I'd say if the user saye font-family="futura, sans-serif,any" he'll get a warning that a fallback was used in case there is no futura or not even a sans-serif font. If the user says font-family="futura" and there is no futura font, FOP should terminate. After all, the user hopefully thought about it.
Makes sense.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
