J.Pietschmann wrote:
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 B. West <http://www.powerup.com.au/~pbwest/resume.html>

Reply via email to