Ghostscript：使用“gxps”生成可搜索的 PDF答案

【问题标题】：Ghostscript: producing searchable PDF with 'gxps'Ghostscript：使用“gxps”生成可搜索的 PDF
【发布时间】：2015-06-17 20:09:51
【问题描述】：

我有一个可搜索的 XPS 文件，我将其转换为 PDF，如下所示：

gxps -sOutputFile=C:\temp\foo.pdf -sDEVICE=pdfwrite \
     -dNOPAUSE C:\temp\foo.xps

生成的 PDF 不可搜索。

gxps 有没有办法生成可搜索的 PDF？
如果没有，是否有类似的应用程序可以在命令行上将可搜索的 XPS 转换为可搜索的 PDF？

编辑：

gxps version: 9.15
Build date: Mon Sep 22 12:35:05 2014

输入 XPS 文件示例：https://www.dropbox.com/s/01rd7apzjb1kwuo/forSO.xps?dl=0
示例输出 PDF 文件：https://www.dropbox.com/s/pefslcyznns5gim/forSO.pdf?dl=0

【问题讨论】：

了解您使用的 GhostScript 版本（gxps 版本与 GS 版本同步）以及查看此类文件的示例会很有帮助。将 XPS 文件转换为 PDF 并创建 ToUnicode CMa 可能会也可能不会，但目前我怀疑 gxps 是否会这样做。如果输入中没有 ToUnicode CMap（不能在 XPS 文件中），则 PDF 将不包含一个，那么可搜索性完全取决于启发式和字符代码映射。我认为从技术上讲应该可以做到。
你能提供一个（链接到）XPS 输入文件示例吗？
在那里，我添加了 GhostScript 版本和示例文件。感谢您的帮助！

标签： pdf ghostscript xps

【解决方案1】：

我查看了 PDF 并快速调查了 GXPS 用于生成 PDF 文件的字体，使用 pdffonts：

 $ pdffonts forSO.pdf

   name                    type         encoding         emb sub uni object ID
   ----------------------- ------------ ---------------- --- --- --- ---------
   RFGWZI+Arial            TrueType     WinAnsi          yes yes yes     11  0

表面上看起来还不错：

唯一使用的字体是嵌入的（参见emb 列）。
字体类型是常见的（见type专栏）。
字体编码是标准的（参见encoding 列）。
字体似乎有一个配套的/ToUnicode 映射（参见uni 列）。

然而，仔细观察，gxps 嵌入到 PDF 中的真正的/ToUnicode 映射似乎是严重的 b0rken。这是它，从 PDF 中提取为完整的间接对象，带有未压缩的流：

41 0 obj
<<
  /Length 863
>>
stream
/CIDInit /ProcSet findresource begin
12 dict begin
begincmap
/CMapType 2 def
/CMapName/R41 def
1 begincodespacerange
<00><ff>
endcodespacerange
42 beginbfrange
<04><04><0004>
<05><05><0004>
<06><06><0006>
<07><07><0006>
<08><08><0006>
<09><09><0006>
<0a><0a><000a>
<0b><0b><000a>
<0c><0c><000c>
<0d><0d><000c>
<0e><11><000e>
<12><12><000c>
<13><13><000c>
<14><14><000c>
<15><15><000c>
<16><16><0004>
<17><17><0004>
<18><18><0004>
<19><1a><0019>
<1b><1b><001a>
<1c><1c><001a>
<1d><1d><001a>
<1e><1e><001a>
<1f><1f><001a>
<20><20><0044>
<21><21><001a>
<22><22><001a>
<23><23><001a>
<24><24><0024>
<25><25><000c>
<26><26><001d>
<27><27><0023>
<28><28><0023>
<29><29><0028>
<41><41><0044>
<44><44><0044>
<49><49><0044>
<63><63><0044>
<69><69><0044>
<74><74><0044>
<76><76><0044>
<79><79><0044>
endbfrange
endcmap
CMapName currentdict /CMap defineresource pop
end end
endstream
endobj

正如我们所见，/ToUnicode 表包含 42 个键，但它们确实只映射到 12 个不同的字符值：

这 12 个不同的字符值中的一些值在此表中多次出现，因此将多个字形反向映射到同一个字符（这反过来似乎对单个字符也不正确）：

     no. of |   char 
occurrences |   value
------------+-----------
         1  |   <000e>
         1  |   <0019>
         1  |   <001d>
         1  |   <0024>
         1  |   <0028>
         2  |   <000a>
         2  |   <0023>
         4  |   <0006>
         5  |   <0004>
         7  |   <000c>
         8  |   <001a>
         9  |   <0044>

例如，字符值06 映射到具有数字06、07、08 和09 的字形。

这看起来不对。

恕我直言，这值得向 Ghostscript's Bugzilla 报告错误（但我不确定 GXPS 组件是否仍在积极维护中）。

更新：我在这里找到了 Ghostscript/GXPS bugzilla 数据库的现有条目：

Bug 693945 - Incorrect Unicode Map Generated by gxps/pdfwrite

【讨论】：