Font embedding : multiple subsets versus merged subsets.
Posted: Mon Jul 17, 2017 1:11 pm
I have modified the Word document uploaded by Willy.
In Willy's version (the original), there are in-layperson's-terms six 'fonts', but as each of these were shown in roman, italic and bold (i.e. three variants) there were technically eighteen fonts. When printing this from Word using PDF-XChange Lite V6, with font (subset?) embedding, the resulting PDF generated by Willy contained 18 embedded font (subsets). That makes sense.
In my modified version I copied all of the original text, inserted a couple of blank lines, a page break and a section break, and pasted the copied content onto the two resulting (erstwhile) blank pages. I print this from Word using PDF-XChange Lite V6. Regardless of whether I choose font embedding or not, there are 54 'font' subsets listed under Document Properties in the resulting PDF files. 54 = 3 × 18. So for every subset that has to be embedded/listed, there are another two that are redundant. It seems that PDF-XChange Lite V6 is just tracking 'runs' in which a certain font is used continuously. I had previously considered the possibility that additional subsets would be created if the document were structured like, say: "[Heading in UPPERCASE Palatino] [Text in Arial] [Text in lowercase Palatino]", so that the lowercase characters might/would not be embedded in the first subset of Palatino, but would be needed for the last passage of text. However, this appears in the present testing to be not the case, because in the present testing the text has been repeated verbatim.
See attachments.
Note: files sizes are 13 kB (no embedded fonts) and 2918 kB (embedded 'font' subsets)
Finally, I have tested the "Merge font subsets" functionality under "File: > "Save as Optimized..." in PDF-XChange Editor. This successfully cuts the number of fonts shown in Document Properties back down to 18.
Furthermore, the file size is reduced to 968 kB.
The result of optimization, which apparently retained only the necessary embedding, suggests that the originally produced PDF with embedded fonts contained 968/2918 = 33% useful data and 67% unneeded data.
If that's correct, then it's not clear why the subset merging isn't included as part of the original PDF creation from Lite. The only motivation I can come up with is that it takes more time to merge the various subsets.
In Willy's version (the original), there are in-layperson's-terms six 'fonts', but as each of these were shown in roman, italic and bold (i.e. three variants) there were technically eighteen fonts. When printing this from Word using PDF-XChange Lite V6, with font (subset?) embedding, the resulting PDF generated by Willy contained 18 embedded font (subsets). That makes sense.
In my modified version I copied all of the original text, inserted a couple of blank lines, a page break and a section break, and pasted the copied content onto the two resulting (erstwhile) blank pages. I print this from Word using PDF-XChange Lite V6. Regardless of whether I choose font embedding or not, there are 54 'font' subsets listed under Document Properties in the resulting PDF files. 54 = 3 × 18. So for every subset that has to be embedded/listed, there are another two that are redundant. It seems that PDF-XChange Lite V6 is just tracking 'runs' in which a certain font is used continuously. I had previously considered the possibility that additional subsets would be created if the document were structured like, say: "[Heading in UPPERCASE Palatino] [Text in Arial] [Text in lowercase Palatino]", so that the lowercase characters might/would not be embedded in the first subset of Palatino, but would be needed for the last passage of text. However, this appears in the present testing to be not the case, because in the present testing the text has been repeated verbatim.
See attachments.
Note: files sizes are 13 kB (no embedded fonts) and 2918 kB (embedded 'font' subsets)
Finally, I have tested the "Merge font subsets" functionality under "File: > "Save as Optimized..." in PDF-XChange Editor. This successfully cuts the number of fonts shown in Document Properties back down to 18.
Furthermore, the file size is reduced to 968 kB.
The result of optimization, which apparently retained only the necessary embedding, suggests that the originally produced PDF with embedded fonts contained 968/2918 = 33% useful data and 67% unneeded data.
If that's correct, then it's not clear why the subset merging isn't included as part of the original PDF creation from Lite. The only motivation I can come up with is that it takes more time to merge the various subsets.