On Jun 27, 2007, at 20:49, Loran Kary wrote:
Hi,
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...
Cheers
Andreas
