iOSでPDF検索に使用できる優れたソースがあることを知っています。それはPDFKittenです。
しかし、私の場合、このソースが検索に機能しないPDFファイルに遭遇することがあります。Macの「プレビュー」アプリでこれらのファイルを開こうとしましたが、検索してみましたが、動作します。
ここに1つのファイルをアップロードしました。
このファイルを「プレビュー」アプリで開き、「ra」という単語を検索して確認できます。それは完璧に動作します。このファイルをソースPDFKittenにドラッグし、ソースが開くようにいくつかの構成を行ってから検索しようとすると、機能しません。
ソースを調べたところ、Tj、'、''、TJを含むすべてのテキスト表示演算子が処理されます。これらのオペレーターのコールバックにいくつかのログ行を配置しましたが、これらのコールバックが呼び出されていないことがわかりました。
私にいくつかの提案やアイデアを教えてもらえますか？
コードを正しく理解していれば、PDFKittenはページの/Resourcesディクショナリの/Fontエントリでのみフォントを検索します。少なくとも、これがスキャナーのfontCollectionWithPageメソッドの私の解釈であり、その結果はpdfScannerCallbacksのsetFontによって照会され、現在のフォントオブジェクトを設定します。
さらに、Do演算子（つまり、XObjectリソースのコンテンツをページコンテンツに挿入するために使用される演算子）のコールバックはありません。CGPDFScannerScanが内部でこの演算子を解釈しない限り、含まれているXObjectのコンテンツはまったくスキャンされません。これは、テキスト設定演算子のコールバックが呼び出されないという観察結果と一致します。
ただし、ファイルmundo1.pdfには、そのページの/Resourcesディクショナリに即時の/Fontエントリがありません。代わりに、各ページの実際のコンテンツはすべて、それぞれ単一の/XObjectリソースにラップされます。これらのXObjectには、それぞれのページに使用されるフォントを定義する/Fontエントリを含む独自の/Resourcesディクショナリがあります。
したがって、PDFKittenは、ファイルで使用されているフォント、特にそれらのエンコーディングについて何も知らないため、PDFコンテンツからテキストを抽出することはできません。多分それは解釈するためにPDFの内容を見ることさえできません。
したがって、この号をPDFKitten号管理サイトに投稿することをお勧めします。
ちなみに、このPDF構成は完全にPDF仕様に準拠しています。それにもかかわらず、iTextライブラリの不適切な使用のように見えます。そのようなiTextを使用するソフトウェアの作成者は、自分のコードを確認し、iTextライブラリのより適切なクラスの使用を開始する必要があります。