Or the other tool might simply not care that much and assume based on the partial name match that they are the same. The other tool you listed might actually check whether these fonts are the same (and if they are, embed them only once). If you have 100 documents, all using a subset of the same font, that subset will be embedded 100 times. So it decides to embed both these subsets into the new document. And sadly, it doesn't know whether these fonts are actually the same. PdfSmartCopy has to decide what to do with these resources. I believe it simply adds a random 6-character suffix. Similarly, a second document (again containing a subset of Times New Roman) might list "Times-VHUIEF" as one of its resources. So a document containing a subset of Times New Roman might have "Times-AUHFDI" in its resources. In order to differentiate between a fully embedded font, system font, or subset embedded font, iText generates a new font name for your fonts whenever it embeds them. (I will skip a lot of the technical details.) So what is going wrong exactly when you're merging these documents? This means, instead of embedding the entire font, only those characters that are actually used are embedded in the document. So PDF supports a feature called "font subsetting". I mean, if you are only using the 50-something characters typically used in Western languages, it makes little sense to embed the entire font. The PDF specification took into account that this may be overkill. You can imagine this as simply putting the font file into the PDF document. To do that, a PDF library can decide to embed a font. You see, PDF really strives to preserve your document exactly how you made. Often, the problem is related to embedded fonts.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |