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