背景

Question

我正在使用Ghostscript处理一些PDF以减小尺寸。有时处理时嵌入的字体不如查看原始字体时使用的本地字体。

几个问题：

我认为已经嵌入在输入PDF中的字体会在输出PDF中重复使用，而不是从本地计算机中获取。它是否正确？即使启用了子集化，这是真的吗？
Ghostscript在严格匹配时是否可以（并合理地）嵌入缺少的字体？
Ghostscript是否可以保留已经嵌入在输入PDF中的字体，但是不打算嵌入源中缺少的字体？

背景

目前我正在使用Ghostscript 9.23的以下命令：

gs -sDEVICE=pdfwrite \
   -dCompatibilityLevel=1.4 \
   -dDownsampleColorImages=true \
   -dDownsampleGrayImages=true \
   -dDownsampleMonoImages=true \
   -dColorImageResolution=72 \
   -dGrayImageResolution=72 \
   -dMonoImageResolution=72 \
   -dColorImageDownsampleThreshold=1.0 \
   -dGrayImageDownsampleThreshold=1.0 \
   -dMonoImageDownsampleThreshold=1.0 \
   -dNOPAUSE -dQUIET -dPARANOIDSAFER -dBATCH \
   -dDetectDuplicateImages=true \
   -sOutputFile=output.pdf input.pdf

但是，在某些情况下，字体重映射似乎会损害渲染结果。下面是一种情况，在没有任何嵌入字体的源PDF中，在字体替换和嵌入之后，典型的查看器会出现渲染性降低的情况：

在：

name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
FrizQuadrata-Bold                    Type 1            MacRoman         no  no  no       7  0
Helvetica-Black                      Type 1            MacRoman         no  no  no       9  0
Helvetica-Light                      Type 1            MacRoman         no  no  no      59  0
Helvetica-Bold                       TrueType          MacRoman         no  no  no      65  0
Helvetica-Bold                       Type 1            MacRoman         no  no  no      68  0
ZapfDingbats                         Type 1            Custom           no  no  no      70  0
Helvetica-Black                      Type 1            MacRoman         no  no  no     108  0
Helvetica-BlackOblique               Type 1            MacRoman         no  no  no     136  0
ZapfDingbats                         Type 1            Custom           no  no  no     137  0
Helvetica-Bold                       Type 1            MacRoman         no  no  no     780  0
Helvetica-LightOblique               Type 1            MacRoman         no  no  no     926  0

后：

name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
VRGBBC+Times-Bold                    Type 1C           MacRoman         yes yes no       8  0
JTHLZY+Helvetica-Bold                Type 1C           MacRoman         yes yes no      10  0
ETQHWQ+Helvetica                     Type 1C           MacRoman         yes yes no      20  0
ZapfDingbats                         Type 1            ZapfDingbats     no  no  yes     29  0
LSUJJC+Helvetica-BoldOblique         Type 1C           MacRoman         yes yes no      46  0
RBDUAX+Helvetica-Oblique             Type 1C           MacRoman         yes yes no     202  0

Answer 1

这里有很多答案......

I imagine that fonts which are already embedded in an input PDF are reused in the output PDF rather than sourced from the local
机。它是否正确？即使在子集化时也是如此启用？

当您创建新的PDF文件时，Ghostscript的pdfwrite设备默认会保留输入中可能包含的所有内容。这对字体来说实际上非常重要。

Is it possible (and reasonably) to have Ghostscript only embed a missing font when it has a strict match?

你如何定义一个严格的匹配＆＃39; ？

Is it possible for Ghostscript to retain fonts already embedded in the input PDF but not bother embedding fonts that are missing in the

源？

您当然可以调整Ghostscript的pdfwrite设备嵌入字体的方式，有几个控件，都记录在案。 AlwaysEmbed，NeverEmbed数组允许您阻止嵌入某些命名字体，还有EmbedAlllFonts和SubsetFonts。

尝试使用测试文档将EmbedAllFonts设置为false（重要也将SubsetFonts设置为false）。我还建议您共享一个显示问题的PDF文件，因为很难理解为什么会出现问题。一些退化＆＃39;并没有真正告诉我。嵌入的字体（除了FrizQuadrata，Helvetica-Black，Helvetica-BlackOblique和Helvetica-LightOblique）都是基础13的一部分，因此应该没问题。

不在PDF文件中嵌入字体（除了基础13之外）是一个坏主意，它应该是可移植的，如果你依赖字体替换，你总是冒着风险渲染结果不正确。

大概你实际上在本地有这些字体，那么为什么不让它们可用于Ghostscript以便pdfwrite设备可以在新的PDF文件中嵌入字体的子集？然后它将是便携式的。

限制Ghostscript中有问题的字体映射

背景

1 个答案: