为什么Ghostscript中的PDF优化后搜索结果会发生变化？

在Ghostscript优化之前，在Link的PDF文件中搜索单词find时，结果会给出第4,7和13页，但是优化之后它只给出第4页和第13页，而忽略第7页，优化：为什么Ghostscript中的PDF优化后搜索结果会发生变化？

D:/gswin64c -sDEVICE=pdfwrite -dMaxSubsetPct=100 -dAutoRotatePages=/None -dMaxInlineImageSize=0 -dPDFSETTINGS=/ebook -dColorImageResolution=96 -dDetectDuplicateImages=true -dColorImageDownsampleThreshold=1.1 -dDOPDFMARKS -dUseTrimBox -sOutputFile="D:/temp/search_text.pdf" -dNOPAUSE -dNOGC -dBATCH -dNumRenderingThreads=8 -c 50000000 setvmthreshold -f "D:/temp/iphone_user_guide.pdf"

我试图添加相关参数的脚本几个字体，如-dEmbedAllFonts =真实，指向字体路径还我试图通过消除一些，但没有与参数玩结果这可能是导致此问题的原因？

来源

2014-08-28 user1283633

Ghostscript不会做'优化'。看到这里我的答案：

GhostScript issues with a CropBox

一些详情，以了解它所做的。

无法看到您的文件我无法确定它们之间的区别是什么，但很可能由于某些原因，缺失的文本被绘制为图像而不是文本。

顺便说一句，你发送的选项很多都没有效果（例如NumRenderingThreads，对于不会渲染的设备）。你不应该选择-dNOGC，这是一个非常糟糕的主意，-dDOPDFMARKS已经被设置为pdfwrite设备。

来源

2014-08-28 07:11:43 KenS

如果您单击我的问题中的链接，您可以找到该文件，但是如何确保该文件已被优化，并且文本被移动为文本未绘制为图像？ – user1283633 2014-08-28 07:30:27

正如我在链接中指出的那样，Ghostscript和pdfwrite根本不会“优化”文件。基本原因是您的原始PDF文件具有特殊的ToUnicode CMAp，并且由pdfwrite生成的ToUnicode CMap不是同样，所以你会得到一个奇怪的结果。对于它的价值，在该页面上找到的'f'不是'f'，它是一个连字符，所以ToUnicode映射必须有两个字符，0x0066和0x0069，这似乎是问题的根源。 – KenS 2014-08-28 11:22:55

谢谢你的回答，但我有这些最后的问题你是如何得出这个结果的独特的unicode结果？而下一个'f'部分不是'f'？你建议如何保留文本？ – user1283633 2014-08-28 13:55:11

为什么Ghostscript中的PDF优化后搜索结果会发生变化？

回答

相关问题