You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by steve poling <sd...@i2k.com> on 2010/01/04 08:24:29 UTC

Concerning bug 490

(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