(Apologies if I'm violating protocol posting this to the pdfbox-dev list.)

When a TTF font is embedded in a PDF file, it is encoded as Adobe specifies in a "Dictionary" object. This Dictionary is extracted by Pdfbox and carried forward without alteration until it is needed for rendering. This is done by passing the data to a java.awt.font constructor. This constructor expects to see the bits you'd find in a TTF file. However, the embedded TTF font has not been embedded in its entirety. Pdfbox presents this data bock to the constructor and the constructor throws an exception with the message that the TTF data is missing a name.

When I examine this data block, I see that it closely resembles a TTF file, but not the whole thing. It appears that when the TTF font is embedded in a PDF file, Adobe (or whoever) is creating the PDF file, discards some data (e.g. the font name) with the intention (I suppose) of tracking that info separately.

It appears that what pdfbox must do to resolve pdfbox-490 is to supplement the data block before passing it to the java.awt.font constructor, specifically adding back the data (e.g. font name) that was stripped when the TTF was originally embedded.

Does this sound plausible and/or correspond to your understanding of the problem underlying this issue?

Cordially,

steve

Reply via email to