如何确认TrueType PDF字体缺少字形 [英] How to confirm a TrueType PDF font is missing glyphs

问题描述

我有一个PDF在Acrobat中很好的渲染，但在打印机RIP的PDF到PS转换过程中无法打印。在使用pdftk进行解压缩和编辑之后，我发现如果我替换某个字体的用法，它将会打印。

字体是一个奇怪的字体，单个字符（空格）。

如果我通过Ghostscript传递PDF，它不会报错，但是Acrobat的飞行前检查会报告一个缺失的字形空间。原始文件不报告此错误。我刚刚使用了一个基本的命令：gswin32c -dBATCH -dNOPAUSE -sDEVICE = pdfwrite -o gs.pdf original_sample.pdf

原始PDF并保存。运行TTFDUMP.exe会产生一个有趣的结果，看起来'glyf'表丢失了：

  4。 'glyf' -  chksm = 0x00000000，off = 0x00000979，len = 0 
 5.'head' -  chksm = 0xE463EA67，off = 0x00000979，len = 54 
  

只是想知道，我能正确解释这个结果吗？从PDF提取的数据上运行TTFDUMP是否有效？我认为根据规范需要一个glyf表，至少是前四个必要的字符。

在ghostscript PDF上运行的TTFDUMP产生了类似的结果，但是一个1字节的glyf表。

如果是这样的话，看起来Acrobat并不特别在乎其他程序（包括打印机）在空间上的缺失。这是奇怪的，它没有被报告为失踪，直到它通过Ghostscript运行。

PDF是由Adobe InDesign创建的，字体的版权像大多数，所以我不能分享它。

编辑 - 我接受了Ken的答案，因为他帮助我处理Ghostscript bug跟踪器。总而言之，由于缺少glyf表，字体似乎被打破。在我听到其他消息之前，我将不得不假设这是InDesign中的一个错误，并且会继续调查。

解决方案

是的，你可以在一个嵌入的子集字体上运行ttfdump，它仍然是一个完全有效的字体。

缺少的字形不是特别的问题，因为使用了.notdef字形相反，缺少.notdef意味着字体不合法。

我认为您误解了共享PDF文件的合法性（从字体的角度来看嵌入）。实际上，您看到的每个PDF文件都将包含版权字体，但是这些文件可以作为PDF（或PostScript）文件的一部分进行嵌入和分发。 TrueType字体包含控制字体的DRM的标志，并且可以拒绝以PDF（或其他格式）嵌入。与Acrobat Distiller和其他Adobe产品一样，Ghostscript也赞同这些嵌入标志。

有些字体会在无意中随DRM一起提供，从而阻止了嵌入，而且还有一个列表其中，字体铸造厂的明确声明允许嵌入这些字体。我认为这是几年前在Adobe网站上的某个地方。

因此，如果你有一个嵌入了字体的PDF文件（尤其是如果它是由一个Adobe应用程序），那么我会很舒服，它的合法分享。

我有一些麻烦，找出问题的实际是什么，以及如何使用Ghostscript 。如果你正在运行PDF-> PS然后回到PDF，那么所有的投注都是坦率的。往返文件通常会引发问题。

无论如何，我很高兴看到这个文件，但是您必须将其提供给您。

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.

The font is a strange one, a TrueType subset with a single character (space).

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

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:

4. 'glyf' - chksm = 0x00000000, off = 0x00000979, len =        0
5. 'head' - chksm = 0xE463EA67, off = 0x00000979, len =       54

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.

TTFDUMP run on the ghostscript PDF produces a similar result but with a 1-byte 'glyf' table.

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.

The PDF is created by Adobe InDesign and the font is copyrighted like most so I can't share it.

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.

解决方案

Yes you can run ttfdump on an embedded subset font, its still a perfectly valid font.

A missing glyph is not specifically a problem, because the .notdef glyph is used instead, a missing .notdef means a font isn't legal.

I think you are mistaken about the legality of sharing the PDF file (from the point of view of font embedding). Practically every PDF file you see will contain copyright fonts, but these are permitted to be embedded and distributed as part of a PDF (or indeed PostScript) file. TrueType fonts contain flags which control the DRM of the font, and which can deny embedding in in PDF (or other formats). Ghostscript honours these embedding flags in the font as does Acrobat Distiller and other Adobe products.

There were some fonts which inadvertently shipped with DRM which prevented embedding, and there's a list somewhere of these, along with an explicit statement from the font foundry that its permissible to embed these fonts. I think this was somewhere on the Adobe web site a few years back.

So if you have a PDF file with the font embedded in it (especially if it was produced by an Adobe application) then I would be comfortable that its legal to share.

I'm having some trouble figuring out what the problem actually is, and how you are using Ghostscript. If you are running the PDF->PS and then back to PDF then all bets are off frankly. Round-tripping files will often provoke problems.

In any event I'm happy to look at the file but you will have to make it available.

这篇关于如何确认TrueType PDF字体缺少字形的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！