J.Pietschmann wrote: > > (Still not making sense? If you need any more intermediate steps in > > understanding how getters and setters actually make things > work, we're just > > a message away ;) ) > > Dunno. Let me elaborate. > We have > FO -> FOP layout -> FOP renderer -> output > Font variant SmallCaps can be implemented in several ways > - Get a SmallCaps font and use it. The handling is the same as > for bold and italic (or "font-weight" and "font-style") > - Emulate by uppercasing lowercase characters and set an 80% > size font for them before the text is laid out (maintenance > branch implementation) > - pass the attribute into the renderer or into the output and > let them care for themself > > The layout needs font metrics, therefore from the point of view > of the layout the first and third option are the same. > The interesting point is whether option 2 is implemented, somewhere > in the pipeling before individual character widths are used (and, > if necessary, character height), or whether the layout can get its > metrics form a FOP Font structure (FontState or whatever it is called > now).
The new logic that I envision on Fonts (subject to Jeremias' approval especially, and everyone else's in general) makes a distinction between Typeface and Font. A Font is a Typeface rendered at a specific point size. A Typeface roughly corresponds to what is contained in a ttf of pfa font file. So when a Font object is tied to an object, it can handle both cases fine. The FO Tree logic that determines which font object to use will have to determine whether a true small-caps typeface exists for the TypefaceFamily, and act accordingly. But everything downstream from there can simply use the stored Font object. > If the font approach is used, we need "font variant" to be a font > attribute. I'm too lazy to check whether this is already in place. > The maintenance code didn't have it. I don't think it is. The idea is to have a TypeFaceFamily object that knows the relationship between the variations of the Typeface (i.e. bold, italic, small-caps). So each Font belongs to a Typeface, which in turn belongs to a TypeFaceFamily. So referencing a parent TypeFaceFamily can determine whether there is a related small-caps Typeface. > The advantage of this approach compared to the "early emulation" > approach is that if a user has a true small caps font, he can use > it more easily. For FOP, there is still the problem what to do if > there is no appropriate font. Just bailing out might be an idea, > but not necessarily a good one. An alternative would be to let the > emulation happen under control of the font, in the renderer. This > would need some hooks which don't exist yet, because the emulation > must be able to insert the font size change into the output. I don't understand what you are saying here. If emulation is used, it should probably at least be logged. Alternatively, a config option could control whether this is allowed at all. But I don't follow at all what you are suggesting with the renderer using the font to control the emulation. How does layout get done at all then? And what is the advantage over simply establishing the emulation in the FO Tree itself? > Now the questions is: how should the implementation look in HEAD? > I personally like the font+late emulation approach. > > J.Pietschmann Victor Mote
