I've noted some things here:
http://wiki.apache.org/xmlgraphics-fop/FontSelectionStrategy

It's best to use that page to gather thoughts and come up with a plan to
implement that feature.

On 27.06.2007 22:54:44 Andreas L Delmelle wrote:
> 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



Jeremias Maerki

Reply via email to