How to confirm TrueType PDF font is missing glyphs
I have a PDF that renders fine in Acrobat but does not print during the PDF to PS conversion process on our RIP printer. After uncompressing with pdftk and editing, I found that if I replace using a specific font, it prints.
The font is strange, a subset of TrueType with a single character (space).
If I upload the PDF via Ghostscript it does not report errors, however Acrobat pre-check will report missing glyph for space. This error is not listed for the original file. I just use the basic command: gswin32c -dBATCH -dNOPAUSE -sDEVICE = pdfwrite -o gs.pdf original_sample.pdf
I pulled the font data from the original PDF and saved it. Running TTFDUMP.exe produces an interesting result when the glyf table appears to be missing:
4. 'glyf' - chksm = 0x00000000, off = 0x00000979, len = 0
5. 'head' - chksm = 0xE463EA67, off = 0x00000979, len = 54
Just wondering if I am interpreting this result correctly? Is it possible to run TTFDUMP on extracted data from PDF? I think the "glyf" table is required based on the spec, for at least the first 4 required characters.
Running TTFDUMP on a ghostscript PDF gives the same result, but with a 1-byte "glyf" table.
If so, it seems like Acrobat doesn't really care about the missing space while other programs (including the printer). It's weird that it isn't reported as missing, though until it gets through Ghostscript.
The PDF is created by Adobe InDesign and the font is copyrighted as I cannot share it.
Edit - I accepted Ken's answer when he helped me with the Ghostscript bug tracker. So it appears that the font is broken as intended due to the missing glyph table. Until I hear about this, I must assume that this is a bug in InDesign and will investigate further.
source to share
Yes, you can run ttfdump on a subset inline font, its still a perfectly valid font.
The missing glyph is not a particular problem because the .notdef glyph is used instead, the missing .notdef means the font is not legal.
I think you are wrong about the legality of the PDF file exchange (in terms of font embedding). Pretty much every PDF file you see will contain copyright fonts, but they can be embedded and redistributed as part of a PDF (or even PostScript) file. TrueType fonts contain flags that control the DRM of the font, which may prevent embedding in PDF (or other formats). Ghostscript evaluates these embedding flags in a font like Acrobat Distiller and other Adobe products.
There were some fonts that were inadvertently shipped with DRM that got in the way of embedding, and there is a list of them in there, as well as an explicit indication from the foundry font that it's acceptable to embed those fonts. I think it was somewhere on the Adobe website a few years ago.
So, if you have a PDF file with a font embedded in it (especially if it was created by an Adobe application), then I would be comfortable that it is legal to share.
I am having trouble figuring out the root of the problem and how you are using Ghostscript. If you run PDF-> PS and then back to PDF, then all the bets go frankly. Round trip files often cause problems.
I'm glad to see the file anyway, but you'll need to make it available.
source to share