結果を強調表示してPDFドキュメント内の文字列を検索するためにPDFKittenを使用しています。FastPDFKit またはその他の商用ライブラリはオプションではないため、要件に最も近いものに固執しました。
スクリーンショットでわかるように、最後の文字列を除いて常に正しく強調表示されている文字列「in」を検索しました。"in" の強調表示されたボックスが 40% 近く間違っている、より複雑な PDF ドキュメントを取得しました。
構文全体を読み、課題トラッカーを確認しましたが、行の高さの問題を除いて、幅の計算に関しては何も見つかりませんでした。今のところ、計算が間違っている、または間違っている可能性があるパターンは見当たりません。
私の現在の予想は、フォント クラスまたは RenderingState.m のどこかで座標と文字幅が間違って計算されていることです。このプロジェクトは非常に複雑で、あなたの誰かが過去に PDFKitten で同様の問題を抱えていたかもしれません。
スクリーンショットには、PDFKitten の元のサンプル PDF ドキュメントを使用しました。
これは、文字識別子が Unicode 文字コードと一致しない文字の幅を計算するときの PDFKitten のバグである可能性があります。
StringDetector の appendPDFString は、文字列データを処理するときに 2 つの文字列を処理します。
// Use CID string for font-related computations.
NSString *cidString = [font stringWithPDFString:string];
// Use Unicode string to compare with user input.
NSString *unicodeString = [[font stringWithPDFString:string] lowercaseString];
Font の stringWithPDFString は、引数の一連の文字識別子を Unicode 文字列に変換します。
したがって、変数の名前にもかかわらず、cidString は一連の文字識別子ではなく、Unicode 文字ではありません。それにもかかわらず、そのエントリは、スキャナーで文字幅によって位置を転送するために実装されている didScanCharacter の引数として使用されます。文字幅を決定するために Font の widthOfCharacter のパラメーターとして値を使用し、そのメソッド (コメント「Width fontsize にスケーリングされた指定された文字 (CID) の ") は、その引数が文字識別子であると想定しています。
そのため、CID と Unicode 文字コードが一致しない場合、間違った文字幅が決定され、後続の文字の位置が信頼できなくなります。この例では、/fi 合字の CID は 12 で、Unicode コード 0xfb01 とは大きく異なります。
PDFKitten を強化して StringDetector の didScanCID メソッドも定義することを提案します。このメソッドは、CID を転送する処理済みの各文字に対して、appendPDFString で didScanCharacter の次に呼び出される必要があります。スキャナは、代わりにこの新しいメソッドを使用して、カーソルを転送する幅を計算する必要があります。
ただし、これは最初にトリプルチェックする必要があります。おそらく、いくつかの widthOfCharacter 実装 (フォントの種類ごとに異なるものがあります) は、コメントにもかかわらず、引数が結局 Unicode コードであることを期待しています...
(あちこちで間違った語彙を使用していたら申し訳ありません。私は「Javaガイ... :)」)