Hi, Gesendet: Mo, 04. Jan 2010 Von: steve poling<[email protected]>
> (Apologies if I'm violating protocol posting this to the pdfbox-dev list.) No problem at all. > 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? Thanks for your investigation and detailed description. Your understanding is correct. I already tried to explain that in the description of PDFBOX-490 [1], perhaps my attempt wasn't detailed enough. I also tried to describe to possible solutions for that issue. > Cordially, > > steve BR Andreas Lehmkühler [1] https://issues.apache.org/jira/browse/PDFBOX-490
