On Jun 27, 2007, at 20:49, Loran Kary wrote:


I see there was a recent thread on fop-user called "Mixing Languages and Unicode". I have the same problem. The PDFs that I create with FOP could potentially contain any mix of languages and no one font will support them all.

I do not believe it is practical to try to implement a character-by- character font selection strategy in XSLT, even if I could figure out how to do it. Nor do I believe it is practical to try to create some custom font that supports all languages and embed that in all my PDFs.

I agree. Implementing something like this in XSLT is indeed a complete waste here. As for custom fonts supporting all possible Unicode-characters, they tend to blow up the resulting PDF's size when embedded...

Font-selection is precisely why --I think-- the Recommendation states that in the first step of formatting, all 'characters are converted in character FOs' (in 1.1.2 Formatting). One could even argue that FOP is not compliant to the Rec here, as it treats contiguous blocks of text in the source XML internally as one character array.

So my question is, what would it take to implement support for the font-selection-strategy property?

Now, /there/ is a GOOD question to ask first! 8-)
Always make /us/ think about that first, before nagging about possible plans to implement. Nice strategy. I like your style. :-)

Come to think of it, a little understanding of FOP's internals and the implied Java-knowledge should be enough. No need to touch the layoutengine for this, if I judge correctly. We could implement this at the point where the FOText instances are processed, since the font- family info is already available at that point (and hence, there is the possibility to check for codepoints that have no glyph).

We could do a substitution to character FO's for codepoints outside the default font's mapping...



Reply via email to