The objects to which this particular FO property applies would need to be _able_ to use the getters and setters (which does not seem to be the case in any of the classes at the moment) to activate the code in fonts, not? Or, the code in fonts should be _able_ to use them at the very least (--which I can only guess to be the idea, from the corresponding variable declarations being commented out, these would be replaced by a call to getFontVariant() )
(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).
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.
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.
Now the questions is: how should the implementation look in HEAD? I personally like the font+late emulation approach.
J.Pietschmann
