Hi Alexandros

Would you mind attaching your patch to a new Bugzilla issue?
We usually work with Bugzilla tickets for contributor patches for better

I've had a short look at your patch. The functionality looks good. I'll
touch up the formatting a bit. There are some conflicts with the current
FOP Trunk due to the addition of generics but that's easily fixed. Just
attach your patch as is.


On 28.01.2011 10:41:26 Papadakis, Alexandros wrote:
> Dear All,
> We have an issue regarding the generation of postscript documents using a 
> custom type1 font in the greek language. The font we tried is called kerkis 
> (can be found @ http://iris.math.aegean.gr/kerkis/Kerkis_for_LaTeX.zip),
> but the same behaviour is observed using true type fonts that we have 
> converted to type1 using open source tools (like fontforge).
> Trying to render the attached sample.fo with the config given, Fop complaints 
> with the following message:
> org.apache.fop.events.LoggingEventListener processEvent WARNING: Glyph "?" 
> (0x394, Deltagreek) not available in font "Kerkis".
> org.apache.fop.events.LoggingEventListener processEvent WARNING: Glyph "O" 
> (0x3a9, Omegagreek) not available in font "Kerkis".
> Our fonts, have glyphs named Omega and Delta - only. Browsing around we found 
> that basically, the code 0x3a9 is equivalent to 0x2126 (Omega) and 0x394 to 
> 0x2206 (Delta). Apparently there are other codes for the Cyrilic version of 
> Omega and Delta, that actually "point" to the same glyph. These are all 
> defined in xmlgraphics-commons library, in 
> org.apache.xmlgraphics.fonts.Glyphs classm put they point to different glyph 
> names, like:
> Omega;2126
> Omegacyrillic;0460
> Omegagreek;03A9
> Omegaroundcyrillic;047A
> Omegatitlocyrillic;047C
> And
> Delta;2206
> Deltagreek;0394
> Fop uses this class to resolve codes to glyph names, and then uses this name 
> to look the glyph in the font, thus producing the error you see.
> I am attaching a patch to be applied to org.apache.fop.fonts.SingleByteFont. 
> It kind-of mimics the behaviour of fallbackMap in class 
> AbstractCodePointMapping where alternative names for a glyph are searched 
> before returning a not found character. 
> This solves our problem with producing readable postscript files but we are 
> wondering if this is the right way to go and if it is well done.
> Can someone check our findings and the patch and/or provide some hints of 
> what would be the best way to workaround this issue in a time efficient 
> manner? Are we missing something in the configuration? 
> Thank you for your time in advance,
> Alexandros

Jeremias Maerki

Reply via email to