Ghostscript 重新编码嵌入字体答案

【问题标题】：Ghostscript re-encoding embedded fontGhostscript 重新编码嵌入字体
【发布时间】：2014-10-25 11:19:04
【问题描述】：

我正在使用 Ghostscript (9.14) 在使用 pdfwrite 驱动程序分发之前“清理” PDF 虽然它通常工作得很好，但我注意到它经常重新编码嵌入式字体，通常有防止用于搜索等的合理文本提取的效果。

ghostscript 处理之前的示例文件在这里：http://download.vistair.com/ghostscript/in.pdf 用ghostscript处理后的结果在这里：http://download.vistair.com/ghostscript/out.pdf

可以使用输入文件提取合理的文本，但不能使用输出文件。

查看 PDF，在我们的输入文件中：

obj 9 0
 Type: /Font
 Referencing: 12 0 R, 14 0 R

  <<
    /BaseFont /GCCBBY+TT187t00
    /Encoding 12 0 R
    /FirstChar 1
    /FontDescriptor 14 0 R
    /LastChar 41
    /Subtype /TrueType
    /Type /Font
    /Widths [352 684 633 973 596 427 636 636 636 636 751 632 684 616 695 787 989 421 748 686 575 601 521 633 521 394 274 607 633 623 623 274 352 364 698 623 623 592 592 592 636]
  >>


obj 12 0
 Type: /Encoding
 Referencing:

  <<
    /BaseEncoding /WinAnsiEncoding
    /Differences [1/space/S/u/m/e/r/two/zero/one/four/H/E/A/T/R/O/W/I/N/B/F/a/c/h/s/t/i/o/n/p/b/l/f/period/C/d/g/y/v/k/endash]
    /Type /Encoding
  >>

在 ghostscript 处理的文件中，这变成了：

obj 8 0
 Type: /Font
 Referencing: 9 0 R

  <<
    /BaseFont /OWPYKO+TT187t00
    /FontDescriptor 9 0 R
    /Type /Font
    /FirstChar 2
    /LastChar 6
    /Widths [ 684 633 973 596 427]
    /Subtype /TrueType
  >>

所以字体编码信息已经丢失，文本不再可提取。

有没有办法停止 ghostscript 重新编码现有的嵌入字体（或至少保留任何现有的字体编码）？

【问题讨论】：

标签： pdf fonts ghostscript

【解决方案1】：

坦率地说，不。它是一种 TrueType 字体，它们总是被转换为符号字体（由于与 Ghostscript 的工作方式有关的复杂原因）。

在过去，我们确实发出了编码，因为 Acrobat 将对 TrueType 字体使用编码（即使是符号字体，它也不应该这样做）。但是，PDF 规范非常清楚，符号字体不应该指定编码，并且这样做会产生比解决的问题更多的问题，因此我们停止了这样做。

【讨论】：

非常感谢您的明确答复。我从您的回复中得知，近期没有改变这种行为的计划？
改变 TrueType 字体嵌入，使其以理智的方式工作是我长期的待办事项列表，但我必须诚实地说，它肯定不会很快，而且可能永远不会.即使在重写了代码之后，我也不能保证我们能够编写一个可以工作的编码，我们必须先将字体写成非符号字体。
顺便说一句，如果原始 PDF 文件有字体的 ToUnicode CMap，那么我相信结果应该仍然是正确的。如果它没有 ToUnicode CMap，那么您已经进入了启发式算法的领域，Acrobat 正在根据其他内容对您的字体进行测试，这可能是正确的，但肯定不能保证。