当我使用命令gs -sDEVICE=pdfwrite -dNOPAUSE -dBATCH -dNOOUTERSAVE -dSAFER -dPDFSETTINGS=/prepress -dCompressFonts=true -dSubsetFonts=false -dEmbedAllFonts=true -sColorConversionStrategy=RGB -dCompatibilityLevel=1.6 -sOutputFile=output.pdf new27.pdf转换pdf文件时，我得到了新文件。
在Adobe Acrobat Reader中打开该新pdf文件时发现错误： new pdf screenshot
这是原始的pdf字体： original
这是转换后的新pdf字体： new
是否有一个控制ghostscript的参数不会更改嵌入字体？
答案 0 :(得分：0)
好吧，问题在于类型1的字体数据没有被嵌入，并且由于它们是子集名称（并因此使用了自定义编码），因此PDF使用者无法创建有效的替代字体。 / p>
存在FontDescriptors，但没有实际的字体数据。我不知道为什么，我以前从未见过这样的问题，您应该向https://bugs.ghostscript.com报告一个错误。
如果您可以找到（或创建）一个很多的简单示例，这可能会有所帮助，原始文件有4页，并使用18种1型字体，这些字体似乎都没有嵌入到输出中。如果可以创建一个使用一种字体的短文本，则是理想选择。
[更新]
我的一位同事为我查看了文件。问题出在PDF文件中，尤其是字体。每种字体都包含一个/.notdef字形（必需），并且每种字体都以未定义的操作码（0x00）开头。这表示该字体确实损坏。
那么为什么这不会给Acrobat（或者渲染时的Ghostscript）造成问题？
因为通常不使用/.notdef字形，所以仅当您尝试绘制字体中不存在的字形（因此是字体中的必需条目）时才使用它。 ，这是必须出现的唯一字形。
但是，当创建PDF文件时，Ghostscript PDF设备会将Type 1字体转换为更紧凑的形式，即Type1C或CFF字体。这意味着要解析字形描述，并且它必须使用的描述之一是/.notdef，因为所有字体都需要这样做。
当Ghostscript尝试解析/.notdef字形时，它将失败，因此放弃了嵌入字体。它仍然会发出FontDescriptor来尝试生成一个工作文件。如果字体不是子集，则可能找到可用的替换。在这种情况下，因为字体是子集，并且使用了不可能的自定义编码。
字体的其他方面也不太理想，例如，将Font BoundingBox定义为/ FontBBox [0 0 0 0]，这显然是胡说八道。字体名称基本上是垃圾，尝试子集前缀看起来像是不正确的，它应该是XXXXXX +，即6个字符，然后是'+'，而不是3。
顺便说一句，原始帖子中的图片字体名称与您所附加的PDF文件中的字体名称不匹配（一点也不为过）。这意味着我不能绝对确定是否存在相同的问题，但我怀疑是这样。
如果在Adobe Acrobat中打开文件，导出到PostScript，然后尝试使用Adobe Acrobat Distiller从该PostScript创建PDF文件，则会引发错误：
%% [错误：无效字体； OffendingCommand：definefont;错误信息：.notdef --nostringval--] %%
因此，Adobe应用程序在处理字体时也会引发错误。
我不知道您在哪里使用所使用的字体，但是您应该用更好的字体替换它们，因为它们已损坏。
