On 03 Feb 2011, at 21:26, Graeme Kidd wrote: Hi Graeme
> > If adapting FOP to detect Fonts on a character by character basis is not > advisable then I will look into your suggestion of recursive templates on the > text() nodes or if that slows things down too far I will just have to move > onto SAXON. On the one hand, it should prove relatively straightforward to adapt FOP to switch to generating separate boxes for each character in a given font, depending on the value of the font-selection-strategy property. The property is already parsed and bound to the FOs, so all that really needs to be changed is org.apache.fop.layoutmgr.inline.TextLayoutManager, mainly getNextKnuthElements(). It seems conceivable to check if the current character can be rendered in the same font as the previous one, and if not, terminate the word-fragment and start a new one. We would then end up with three consecutive boxes in the example, whereas currently, we only generate one. On the other hand, there is currently still an issue that may prove harder to solve, even with the word-by-word selection. The issue is the alignment of the glyphs in the different fonts. You can check this for yourself if, instead of using fo:inline, you would insert word-joiners (U+2060) in between the characters. That will force FOP to treat each character as its own 'word', and select the correct font for each. You will then notice that the Symbol glyph appears much too low in comparison to the Helvetica glyphs. This issue is mitigated if you use fo:inlines, since those establish their own alignment-context. Regards, Andreas --- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
