爲什麼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優化後搜索結果會發生變化？

回答

相關問題