Re: OpenType CFF support

[Andreas Delmelle <an...@telenet.be>]

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.


Regards

Andreas

Re: OpenType CFF support

[Remko Tronçon <re...@el-tramo.be>]

Hi Andreas,

> Somewhat of a shame that this one hasn't been answered yet... Apologies for
> that!

That's alright, thanks for the response!

> 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.

Right, I took care of that. Actually, FOP already runs succesfully
with OpenType fonts, and generates *a* PDF with the font embedded in
it, but the actual glyphs are still gibberish.

> 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 (?)

I'm still reading up on the inner workings of TrueType, but as far as
I could tell, CFF and TrueType fonts only differ in 2 tables. In the
TrueType case, the crucial part seems to be scanning the bounding
boxes of the glyphs in the GLYF table (which is replaced by the CFF
table in the CFF font). However, the CFF table does not seem to
contain this information, only the actual drawing procedures of the
glyphs (and the other CFF table is about vertical writing, so not
relevant either). I was therefore assuming that information about
glyph bearings and bounding boxes was available in another table, but
I could be wrong. In any case, I'll dig deeper into TrueType and see
that I can understand it in more depth.

cheers,
Remko