On 25 May 2009, at 08:59, Remko Tronçon wrote: Hi Remko,
Somewhat of a shame that this one hasn't been answered yet... Apologies for that!
I have moved this thread to fop-dev@, since this is definitely a development-related question.
If you're not on this list, please subscribe and follow up there.
I'm looking at implementing OpenType CFF support in FOP, and had a few questions.
Cool! Such a contribution would definitely be much appreciated by the community.
I know how to parse the CFF data in an OTF file, but I was wondering what data FOP is actually interested in. I notice that, for normal TrueType glyph data, FOP retrieves the bounding box for each glyph.
However, AFAIK, CFF only has glyph charstring data, plus some global data (such as global bounding boxes). So, apart from ensuring that CFF fonts are embedded properly in PDFs, what's to be done exactly to make FOP support CFF?
The layout engine needs to be able to query the font to check whether a glyph for given character is available, and if so, how much space it will require in the result. This includes any kerning between two subsequent glyphs, if applicable. If you haven't done so already, be sure to have a look at org.apache.fop.fonts.truetype.TTFFontLoader. In its private buildFont() method, currently an UnsupportedOperationException is thrown if it is an OpenType CFF. I'm not knowledgeable enough about the implementation to offer any concrete pointers, but maybe it's possible to start by adding processing there that achieves the same effect currently produced for regular TrueType fonts (?)
Then again, in its current state, FOP queries the font for the width of each individual character separately. Neighboring characters are only taken into account in case of kerning. This means that FOP currently has no built-in support for advanced typography features like ligatures and generic glyph substitution. Also, this method of obtaining the individual glyph widths has performance drawbacks for all Java2D based renderers due to the possibly large amount of calls to the AWT font methods. Taking that into account, it would probably make more sense to rework the interaction, so that we can query the font for lengths of complete words or word-fragments.
Feel free to bounce back more questions, if you decide to go further with this.