> Somewhat of a shame that this one hasn't been answered yet... Apologies for
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.