我正在使用一个工具将大型.pdf文件拆分成更小的部分，并且使用Ghostscript来减少新生成文件的大小。 今天我运行了工具来从itext-paulo-155中分割pdf，并且所有文件似乎都已正确创建。但是，当我从新的和小的.pdf文件中选择并复制字符到文本编辑器时，这些都被破坏了：
ỘỔỎồỌỐỗ ờ. ỌộỏỌ
ọχτφσ Ởωχκκω, Ọυω. • Ọσσ Ọχητχ, ỘỔ
ζσιζς@βςξθν.κιβ •
我将我的ghostscript版本更新到了最新的版本9.15并且它仍在发生。我在代码中设置了以下参数：
gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/screen -dNOPAUSE -dBATCH -dQUIET -sOutputFile=
显然Ghostscript不支持这种看似常见的.pdf文件，它们不是扫描图像。你知道什么会导致这种奇怪的行为吗？我怎么能让ghostscript不腐败这些字符？ 谢谢你的帮助。
答案 0 :(得分：1)
你不是在分裂＆＃39; PDF文件，您将从原始PDF创建许多全新的PDF文件。 Ghostscript解释PDF文件，生成一系列图形基元，然后pdfwrite设备将这些基元重新组合成一个全新的输出文件。
因为你这样做，你也可以应用处理图形基元的控件，例如子集字体，缩小图像，转换颜色空间等。
但是您输出的文件与原始文件不同。如果你想分割文件，请使用像pdftk或MuPDF这样的东西。应用程序将保持数据不变，只是将其吐出到新文件中，Ghostscript不会。
现在，如果文件在屏幕上正确呈现，则 NOT 已损坏。可能无法复制和粘贴文本，但这绝不是一回事。
最可能的问题是原始PDF文件包含字体中的文本但不包含ToUnicode CMap，但它可能包含整个字体，或至少使用类似WinAnsiEncoding编码。
随ToUnicode映射提供，Acrobat和其他查看者可以选择文本。如果没有ToUnicode，那么它们将回归到其他启发式方法。如果文本是拉丁语言，并且字体以拉丁语编码（例如ascii）编码，则复制和粘贴将起作用。
但是，PDFSETTINGS = / screen包括切换到子集字体。一旦字体成为子集，它们就不再具有WinAnsi或ASCII编码。遇到的第一个字符是字符代码1，第二个字符是代码2，依此类推。如果有一个ToUnicode CMap，那么这并不重要，因为它仍然可以检索每个字符的Unicode值。但是，如果没有Unicode信息，则此文本不再是ASCII值这一事实意味着您无法再以可理解的方式复制/粘贴它。
如果你不想要那个，那么就不要启用字体子集，当然这意味着你将不得不停止使用-dPDFSETTINGS，但是无论如何使用它都是一个坏主意，因为它设置了一个数字一次控制，大多数人都不知道他们设置了哪些控件，或者含义是什么。