logo标签列表

Ghostscript：使用'gxps'生成可搜索的PDF

pdfghostscriptxps
3

我有一个可搜索的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
了解您使用的GhostScript版本（gxps版本与GS发布同步），并查看此类文件的示例将会很有帮助。可能可以将XPS文件转换为PDF并创建ToUnicode CMa，但目前我怀疑gxps是否支持此功能。如果输入中没有ToUnicode CMap（在XPS文件中不可能存在），则PDF将不包含该项，可搜索性完全取决于启发式和字符代码映射。从技术上讲，我认为这是可能的。 - KenS
你能提供一个可供测试的 XPS 输入文件样本（链接）吗？ - Kurt Pfeifle
我已经添加了GhostScript版本和示例文件。感谢您的帮助！ - dijxtra
1个回答
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

表面上看起来还可以：

  1. 唯一使用的字体是嵌入式的（见emb列）。
  2. 字体类型是常见的（见type列）。
  3. 字体编码是标准的（见encoding列）。
  4. 该字体似乎有一个配套的/ToUnicode映射（见uni列）。

然而，仔细查看后，由gxps嵌入PDF中的真正/ToUnicode映射似乎严重损坏。这是从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个不同的字符值：

  • Some of these 12 different character values appear multiple times in this table, hence reverse-mapping multiple glyphs to the same character (which in turn does not seem to be correct even for a single one): 

         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>

  • For example, character value 06 maps to glyphs with the numbers 06, 07, 08 and 09.

这看起来不太对。 在我看来，应该向Ghostscript的Bugzilla报告一下错误（但我不确定GXPS组件是否仍在积极维护）。 更新：在这里找到了现有的Ghostscript/GXPS bugzilla数据库条目:
  • Bug 693945 - gxps/pdfwrite生成的Unicode映射不正确
    • 网页内容由stack overflow 提供, 点击上面的
    可以查看英文原文，
    原文链接