Until I hear otherwise I'll have to suppose this is a bug in InDesign, and will continue investigating. In summary, it seems the font is broken as suspected due to the missing glyf table.
Universal type client font glyphs not wokring pdf#
The PDF is created by Adobe InDesign and the font is copyrighted like most so I can't share it.Įdit - I've accepted Ken's answer as he helped me on the Ghostscript bug tracker. It's odd it isn't reported as missing though until it runs through Ghostscript. If so it seems that Acrobat doesn't particularly care about the missing space while other programs (including the printer) do. TTFDUMP run on the ghostscript PDF produces a similar result but with a 1-byte 'glyf' table.
Just wondering, am I interpreting this result correctly? Is it valid to run TTFDUMP like this on extracted data from a PDF? I think a 'glyf' table is required based on the spec, at least for the first 4 necessary characters. Running TTFDUMP.exe produces an interesting result where it seems that the 'glyf' table is missing: 4. I've pulled out the font data from the original PDF and saved it. I'm just using a basic command: gswin32c -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -o gs.pdf original_sample.pdf This error is not reported for the original file. If I pass the PDF through Ghostscript it reports no errors, however an Acrobat pre-flight check will report a missing glyph for space. The font is a strange one, a TrueType subset with a single character (space). After uncompressing with pdftk and editing I've found if I replace the usage of a certain font it will print. I have a PDF which renders fine in Acrobat but fails to print during the PDF to PS conversion process on our printer's RIP.