如何确认TrueType PDF字体缺少字形



我有一个PDF,它在Acrobat中渲染良好,但在打印机RIP上的PDF到PS转换过程中无法打印。在用pdftk解压缩和编辑后,我发现如果我替换某个字体的使用,它就会打印出来。

字体很奇怪,是一个只有一个字符(空格)的TrueType子集。

如果我通过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"表,至少对于前4个必需的字符。

在重影脚本PDF上运行TTFDUMP会产生类似的结果,但会产生一个1字节的"glyf"表。

如果是这样的话,Acrobat似乎不像其他程序(包括打印机)那样特别关心丢失的空间。奇怪的是,直到它运行Ghostscript时,它才被报告为丢失。

PDF是由Adobe InDesign创建的,字体和大多数字体一样受版权保护,所以我不能分享。

编辑-我接受了Ken的回答,因为他在Ghostscript错误跟踪器上帮助了我。总之,由于缺少glyf表,字体似乎已损坏。除非我听到其他消息,否则我将不得不假设这是InDesign中的一个错误,并将继续调查

是的,您可以在嵌入式子集字体上运行ttfdump,它仍然是一种完全有效的字体。

丢失的字形并不是一个特别的问题,因为使用的是.notdef字形,而丢失的.notef意味着字体不合法。

我认为你错了共享PDF文件的合法性(从字体嵌入的角度来看)。实际上,您看到的每个PDF文件都包含版权字体,但这些字体可以作为PDF(或PostScript)文件的一部分嵌入和分发。TrueType字体包含控制字体DRM的标志,并且可以拒绝在PDF(或其他格式)中嵌入。Ghostscript与Acrobat Distiller和其他Adobe产品一样,在字体中使用这些嵌入标志。

DRM无意中附带了一些阻止嵌入的字体,其中有一个列表,以及字体铸造厂的明确声明,允许嵌入这些字体。我想这是几年前Adobe网站上的某个地方。

因此,如果你有一个嵌入了字体的PDF文件(尤其是如果它是由Adobe应用程序生成的),那么我会放心地分享它是合法的。

我很难弄清楚到底是什么问题,以及你是如何使用Ghostscript的。如果你正在运行PDF->PS,然后返回PDF,那么坦率地说,所有的赌注都会落空。往返文件通常会引发问题。

无论如何,我很乐意查看该文件,但您必须提供该文件。

最新更新