このPDFはAbbyyFinereader10によって作成されました。
http://ebooks.zeitr.org/from_abbyy.pdf
最初の文をコピーして貼り付けると、次の(非常に良い)テキスト結果が得られます。
Der"BundDeutscherGymnastik-Schulleiter"wurdeam 20. 1955年11月anläßlicheinerZusammenkunftderLeiterinnen und Leiter der privatendeutschenGymnastik-Ausbildungsstättengegründet。
Ghostscript 9.02(64ビットWindows)で処理した後、次のファイルを取得します。
http://ebooks.zeitr.org/after_ghostscript.pdf
これで、最初の文が奇妙に見えます。各単語の最後の文字の前に余分なスペースがあります。
Der"Bun d Deutsche rGymnastikSchulleiter"wurd e a m20。 11月1955anläßlicheinerZusammenkunf t der Leiterinne n un d Leite r de r private n deutschenGymnastikAusbildungsstättengegründet。
これには、AcrobatReaderで単語全体を検索できないという主な悪影響があります。 Ghostscriptに設定された次の最小限のパラメータで効果を再現できます。
-sDEVICE=pdfwrite ^
-dBATCH ^
-dNOPAUSE ^
-sstdout="myStdOut" ^
-sOutputFile="myDestFile.pdf" ^
mySourceFile.pdf
何か案は?
私はこれが興味深い問題であることに気づき、詳しく調べました...
まず、qpdf
コマンドラインツールを使用してPDFデータストリームを解凍し、両方のファイルのソースコードをよりよく確認できるようにしました。
qpdf.exe ^
--qdf ^
from_abbyy.pdf ^
qdf--from_abbyy.pdf
qpdf.exe ^
--qdf ^
after_ghostscript.pdf ^
qdf--after_ghostscript.pdf
余分なスペースが挿入される最初の発生の1つを見てください(元の文字列 "Bund Deutscher Gymnastik-Schulleiter"が "Bundに変わりますDeutsche r GymnastikSchulleiter ")、次のPDFスニペット:
( Deutsche) Tj
0 Tc
(r) Tj
1 0 0 1 143.236 265.140 Tm %% Tm = 'text matrix' operator
3.569 Tw
0.706 Tc
( Gymnastik-Schulleite) Tj
( Deutsche)Tj
0 Tc
36.235 0 Td %% extra Td = 'move text current point' operator
(r)Tj
2.16501 0 Td %% Td = 'move text current point' instead of Tm
3.569 Tw
0.706 Tc
( Gymnastik-Schulleite)Tj
ここで使用されているPDFグラフィック演算子の意味を少し理解するために、以下に短いリストを示します。
Tj - show text
Tc - set character spacing
Tm - set text matrix
Tw - set Word spacing
Td - move text current point
ご覧のとおり、Ghostscriptは元のTm
(text matrix)演算子をTd
(move text現在のポイント)1つであり、さらに2.16501 0 Td
...これがなぜなのかわかりません。 Ghostscriptのbugzilla[*]にバグレポートを送信し、彼らがそれを解決することに興味があるかどうかを確認します。
ただし、Linux Acrobat Reader 9.4.2を使用し、メニューアクション「ファイル->テキストとして保存...」を使用した場合、この問題は発生しないことに注意してください。この場合、追加のスペースはありません(ただし、いくつかの余分な改行があります)。 Linuxでも、テキストは正しく検索できず、copy'n'paste....を実行すると余分なスペースが表示されます。
[*]完了したら、ここでバグ番号を更新します。
置き換えられたTm
演算子についてもう少し考えた後、これが問題の根本ではないはずだと思います。
そのことに気付いたとき、私はv9.02ではなくGhostscriptv8.71で変換を試みました。そして、私は何を言うべきですか?コピーアンドペーストの問題は、v8.71出力では発生しません。
つまり、Ghostscript 9.02には、8.71にはなかった問題があります。ほとんどの場合、出力PDFに埋め込まれているフォントメトリックに関係しています。上記で引用したPDFスニペットは、v8.71の出力でもv9.02の出力でも同じであるため...
GhostscriptのbugzillaのバグエントリのURL:
このバグはその間に修正されたようです。再度テストしたGhostscriptバージョン(現在のGit(v9.10GIT)またはGhostscript v9.06)では発生しません。
テキストを含むページをスキャンしてPDF)でOCRアプリケーションを実行すると、テキストはページに追加されますが、「テキストレンダリングモード」は非表示に設定されます。そこにありますが、画面(または印刷されている場合は紙)にはレンダリングされません。表示または印刷されるのは、スキャンされた元の画像です。
PDFを編集できます...テキストレンダリングを非表示に設定するPDFコードは次のとおりです:
3 Tr
PDFの一部が圧縮されているため、この文字列は元のfrom_abbyy.pdfにもfrom_ghostscript.pdfにも(まだ)見つかりません。 。したがって、qpdf
を使用して、可能な限りそれらを解凍します。
qpdf \
--qdf \
from_abbyy.pdf \
qdf--from_abbyy.pdf
qpdf \
--qdf \
after_ghostscript.pdf \
qdf--after_ghostscript.pdf
これで、上記の文字列を簡単に見つけることができます(各ファイルに出現するのは1つだけです)。
これをテキストレンダリングの表示モードの1つに切り替えましょう。全体として、次の8つのテキストレンダリングモードから選択できます。
0 - fill glyph shapes
1 - stroke glyph shapes
2 - fill, then stroke glyph shapes
3 - neither fill nor stroke glyph shapes (invisible)
4 - fill and add to path for clipping glyph shapes
5 - stroke glyph shapes and add to path for clipping
6 - fill, then stroke glyph shapes and add path for clipping
7 - add glyph shapes to path for clipping
「塗りつぶし」モードを使用すると、OCRからのテキストは、下にあるスキャン画像の上ではあまり見栄えがよくない可能性があります。したがって、私は「ストローク」バリアントを好みます。だから私は単に上記の行を変更して読む
1 Tr
この変更されたPDFを見ると、デフォルトの線幅が私の好みには太すぎるので、私はそれが好きではありません。また、アウトラインストロークの色は黒(デフォルト)です。最初にスキャンした形状とのコントラストを持たせるために、赤が好きです。したがって、この行の前に、線幅を1/4ポイントに設定するコードを追加します。
.25 w
ストロークの色を赤に設定するその他の方法:
1 0 0 RG
完全な行は次のようになります。
.25 w 1 0 0 RG 1 Tr
それで全部です。
注、「目次」(技術用語ではxref
テーブル)が無効になったため、少し操作しただけでファイルが破損したことに注意してください。それでも、AcrobatReaderまたはAcrobatProfessionalは(文句を言わずに)それを開き、ファイルの外部参照セクションをサイレントに「修復」します。その他PDF視聴者はファイルを拒否する場合がありますが、今のところ気にしません...
結果のスクリーンショットは次のとおりです。 (最初のスクリーンショットはウィンドウ幅にズームされます。) (2番目のスクリーンショットは800%にズームされています。)
赤い輪郭は、スキャンしたテキストを希望どおりに表示できるようにしたものです。
両方のファイルfrom_abbyy.pdfとafter_ghostscript.pdfについて、上記と同じ手順を実行しました。両方の結果をAcrobatReaderの2つの異なるインスタンスで開きました。両方を同じ値にズームして両方のウィンドウを最大化すると、[alt]+[tab]
を使用して両方のファイル間でビューを簡単に切り替えることができます。これは、2つのPDFファイル間の最も細かいレンダリングの違いを明らかにするための良い方法です。
私の結果は:Ghostscript(v9.02)の入力とこのファイルの出力の間に1つのピクセルさえも違いはありません。しかし、テキストをコピーして貼り付けたい場合はかなりの違いがあります。
Ghostscriptバグレポートから:
http://bugs.ghostscript.com/show_bug.cgi?id=692206
私は今問題を再現することができました、そしてそれは8.71からの回帰ではなく、その進行(そしてAdobeの変更)です。
8.71には、無効なToUnicodeCMapを書き込むバグが同梱されていました。誤解を招く矛盾したアドビのドキュメントにより、CMapはCMapとして記述されていましたが、実際にはToUnicodeCMapには独自の互換性のないルールがあります。
ToUnicode CMapsは通常、検索とコピー/貼り付けにのみ使用されます。名前が示すように、文字コードをUnicodeコードポイントにマップするために使用されます。 8.71 PDFファイルのToUnicodeCMapは無効であり、それ以降のバージョンのものは有効であり、Acrobatがそれを使用することがわかっているため、使用されません。
9.2までのAcrobatReaderでは、ToUnicodeデータの存在に違いはないようです。 9.2以降のある時点で、検索メカニズムが変更され、AcrobatはToUnicodeCMapが存在するかどうかに応じて2つの異なるメカニズムを使用しているように見えます。 9.2以降はAcrobatProにアクセスできず、最近Reader Xをインストールしたばかりで、その間に何もありません。
「Unicodeなし」メソッドはAcrobatのすべてのバージョンで機能し、「Unicode」メソッドは新しいバージョンでは失敗します。
FontDescriptorからのToUnicodeCMapへの参照を白い間隔で示すことでこれを示しました。必要に応じて、さまざまなファイルを利用できるようにすることができますが、解凍されているため、ファイルは大きくなります。
検索はPDFでのヒューリスティックな作業であるため、結果を保証することはできません。動作の変更はGhostscriptではなくAcrobatによるものであり、Ghostscriptの変更は本当のバグなので、回帰ではなく進行です。
説明されている問題は表示されません。 'after' PDFファイルをAcrobatProfessional 9.0で開いたところ、テキストが正しくコピーされて貼り付けられました。
GhostscriptはPDFファイルを完全に解釈し、解釈した内容に基づいて新しいPDFファイルを生成します。記録する以外は、元のファイルとは関係ありません。テキストの位置。
PDF)の豊富な機能セットにより、複数の異なる方法を使用して文字を同じ場所に配置することができます。したがって、GSが生成する方法自体に問題や予期しないことはありません。 PDFファイル。
テキストを正しく保存できることを考えると、これは、連続するASCIIとして処理されるときに、2つの「近くの」文字が隣接しているかまたは間にスペースがあるかどうかを決定するAcrobatヒューリスティックの問題です。
フォントが埋め込まれていないという単純な理由で、問題が埋め込まれたフォントメトリックである可能性はないと思います:-)使用されているフォントはHelveticaであり、ドキュメントに埋め込まれていないため、Acrobat(少なくとも私にとっては) ArialMTを使用します。 'original' PDFファイルにもフォントが含まれていないことに注意してください。
私は最終的に報告されたバグを調べますが、すぐには起こらず、私たちがそれについてできる(またはする)ことがあるとは思えません。これはヒューリスティックの必然的な結果であるように私には思えます。 mightフォントを埋め込むのに役立つので、少なくとも一貫性が保たれます。
この問題がフォントの「埋め込み性」に関連しているかどうかを確認するために、Linuxで別の変換を行いました。 Ghostscriptに使用するフォントを埋め込むために、このコマンドラインを使用しました。
gs \
-o after_ghostscriptonlinux.pdf \
-sDEVICE=pdfwrite \
-dPDFSETTINGS=/prepress \
-sEmbedAllFonts=true \
from_abbyy.pdf
Ghostscriptはこの出力を表示します:
GPL Ghostscript SVN PRE-RELEASE 9.02 (2011-02-07)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
Loading NimbusSanL-Regu font from %rom%Resource/Font/NimbusSanL-Regu... 2776276 1420923 2081124 778943 3 done.
Loading NimbusSanL-ReguItal font from %rom%Resource/Font/NimbusSanL-ReguItal... 2853416 1529123 2137980 831640 3 done.
Loading NimbusSanL-Bold font from %rom%Resource/Font/NimbusSanL-Bold... 2970748 1643508 2194836 886454 3 done.
Ghostscriptには、NimbusSanLという名前のフォントファミリのフォントが埋め込まれています。したがって、欠落しているHelveticaの代わりにAcrobat Readerによって画面にレンダリングするために使用されたArialMTはもうありません(上記のuser701996のコメントも参照してください)。 Ghostscriptは、埋め込まれるとすぐにそのフォントの名前をHelveticaに変更することに注意してください。しかし、NimbusSanLはHelveticaのクローンとして作成されたため、これは問題ではありません...
ただし、この出力PDFの場合でも、AcrobatReaderからのコピーアンドペーストはうまく機能しません。 ReaderがHelveticaの代わりにArialMTを使用する必要がなくなったという事実にもかかわらず。 Readerは、埋め込まれているNimbusSanL/Helveticaクローンを使用するようになりました。
これまでのところ、AcrobatReaderまたはAcrobatProfessionalからテキストをコピーして貼り付けることについて次の事実を確立しました。
これは、Windows上のGS XP、およびLinux上のGSの場合です。
Ghostscriptの出力v8.71は機能しますこのファイルには十分です。
これは、Windows上のGS XP、およびLinux上のGSの場合です。
コピーと貼り付けが壊れている出力の場合でも、テキストとして保存...は壊れます。
なぜそうなのか、私はまだ理解していません。しかし、v8.71から9.02への途中でGhostscriptのある種の(おそらくマイナーな)リグレッションとして明らかに見えます。
それでは、他のPDFビューアソフトウェアを「重要な」PDFで試してみましょう:
他にもありますが、すべての「動作中」の読者の間にはごくわずかな違いがありますPDF私の評決がコピー 'n'貼り付け動作。ここにダッシュがない、単語の間にスペースが2つあるなど、その他の理由は現在説明していませんが、おそらく同じ根本原因です。アドビ製品(このファイルのコピーアンドペーストが機能していない)と、一方が持っていたものと「その他の世界」との間の大きなギャップです。