title: How to confirm a TrueType PDF font is missing glyphs
body: <p>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. After uncompressing with pdftk and editing I've found if I replace the usage of a certain font it will print.</p>
  
  <p>The font is a strange one, a TrueType subset with a single character (space).</p>
  
  <p>If I pass the PDF through Ghostscript it reports no errors, however an Acrobat pre-flight check will report a missing glyph for space. This error is not reported for the original file. I'm just using a basic command: gswin32c -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -o gs.pdf original_sample.pdf</p>
  
  <p>I've pulled out the font data from the original PDF and saved it. Running TTFDUMP.exe produces an interesting result where it seems that the 'glyf' table is missing:</p>
  
  <pre><code>4. 'glyf' - chksm = 0x00000000, off = 0x00000979, len =        0
  5. 'head' - chksm = 0xE463EA67, off = 0x00000979, len =       54
  </code></pre>
  
  <p>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.</p>
  
  <p>TTFDUMP run on the ghostscript PDF produces a similar result but with a 1-byte 'glyf' table.</p>
  
  <p>If so it seems that Acrobat doesn't particularly care about the missing space while other programs (including the printer) do. It's odd it isn't reported as missing though until it runs through Ghostscript.</p>
  
  <p>The PDF is created by Adobe InDesign and the font is copyrighted like most so I can't share it.</p>
  
  <p><strong>Edit - I've accepted Ken's answer as he helped me on the Ghostscript bug tracker. In summary, it seems the font is broken as suspected due to the missing glyf table. Until I hear otherwise I'll have to suppose this is a bug in InDesign, and will continue investigating.</strong></p>