1

私はPDFKitten検索機能を使用していますが、これでは特殊文字を検索できないことがわかりました（たとえば、PDFでRAVIの単語があり、その単語を検索するとNULL値が返されるとしましょう。これを解決する方法を教えてください問題。

ありがとう

scanner.m には関数 didScanString があります

void didScanString(CGPDFStringRef pdfString, Scanner *scanner)
{
     NSString *tempStr = (NSString *)CGPDFStringCopyTextString(pdfString);
     NSLog(@"ScanString==%@",tempStr);

NSString *string = [[scanner stringDetector] appendPDFString:pdfString withFont:[scanner currentFont]];
    NSLog(@"didScanString====>>>%@",string);
    [ss appendString:string];
    [[scanner content] appendString: string];
    //NSLog(@"TOTAL: %@",[scanner content]);

}

たとえば、検索 PDF 文字列は MGR KL445 です。上記の関数では、2 つの NSLog 出力が最初に ScanString==MGR KL445™ を示し、2 番目に何も表示されません。

4

1 に答える 1

1

検索テキストRAVI'sには縦のアポストロフィが含まれています。代わりに、その文字の前方または後方に傾斜したバージョンが PDF に含まれていないかどうかを確認しましたか? これらの異なるバージョンは、結局のところ、異なる文字コードを持っています。

PDFKitten が間違った位置で強調表示されているという質問のコンテキストでは、そのライブラリが合字を「非合字」文字グループではなく、単一の合字文字として返すことが明らかになりました。テキストに合字が含まれている場合は、それが原因である可能性があります。

同じ質問の文脈で、PDFKitten フォント データの解析はいくつかの点で不十分であることが判明しました。その質問に応えて、そのような欠陥の 1 つの回避策がコードに追加されましたが、私の目には、一般的なケースは修正されず、いくつかの特殊なケースのみが修正されました。そこでの私の答えの提案。

さらに、一部のフォントには、グリフを Unicode 文字にマッピングするための情報が含まれていません。特殊文字は検索できないとあなたは言います---おそらく、これらの特殊文字は、解析をサポートしていない別のフォントから取得されています。

理論的には、アポストロフィは、テキスト以外のグラフィック演算子を使用して描画された可能性さえあります。その場合、テキスト解析はそれを見つけられません。

これらのアイデアのいずれもあなたのケースを説明していない場合 (または、説明しているかどうかを確認できない場合) は、検査のためにサンプル PDF を提供してください。

編集( Brivo MR355 copy.pdfサンプル ファイルを考慮)

やはりアポストロフィが面倒だと思いますが、今回はMR355 の. 生のページ コンテンツには 2 つの精度があります。

/TT1 1 Tf
0.559 0 Td
(Brivo MR355\222s Ready Bar technology replaces 30 complex inputs with a single control, simplifying scan optimization )Tj

と

/TT1 1 Tf
0.559 0 Td
(Brivo MR355\222s Ready Interface)Tj

どちらの場合もフォント リソース /TT1 が使用され、アポストロフィは 146 10 進数の 8 進数である \222 としてエンコードされます。WinAnsiEncoding の引用権、 PDFDocEncodingの商標です。

/TT1は

/LastChar   146
/BaseFont   /REEDOQ+GEInspira
/Type   /Font
/Subtype    /TrueType
/Encoding   /WinAnsiEncoding
/Widths [232, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 198, 0, 0, 0, 530, 0, 0, 530, 0, 530, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 570, 0, 0, 0, 0, 0, 0, 243, 0, 0, 0, 764, 0, 0, 0, 0, 556, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 545, 545, 482, 545, 509, 297, 545, 544, 210, 0, 0, 210, 836, 544, 537, 545, 545, 341, 437, 317, 544, 474, 736, 471, 474, 427, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 190]
/FontDescriptor 32 0 R
/FirstChar  32

/LastChar が 146 で、/Encoding が /WinAnsiEncoding であると、PDFKitten が \222 を引用符文字として認識しやすくなります。

あなたのコメントの 1 つが、最新の PDFKitten バージョンを使用していないことを示していたので、古いコピーに基づいてコード分析も行います。

そのフォント辞書 ( setEncodingNamedFont.m 内) を解析している間、PDFKitten は文字列 "WinAnsiEncoding" を認識し、enum CharacterEncoding (Font.h) からの WinAnsiEncoding (3) を self.encoding に格納します。その後、生の PDF データを Unicode に変換するとき ( stringWithPDFStringSimpleFont.m 内) を呼び出して返します。

NSString *string = [[NSString alloc] initWithData:rawBytes encoding:self.encoding];

しかし、nsstring.h マップのエンコーディング定数は

NSJapaneseEUCStringEncoding     = 3,

したがって、ここで PDFKitten は生データをEUC-JPエンコードとしてデコードしようとしますが、バイト値が 127 を超える場合は悲惨に失敗し、バイト値が 127 以下は ASCII 文字として解釈されます。

NSString initWithDataは、何らかの理由で初期化が失敗した場合 (たとえば、データがエンコードに有効なデータを表していない場合) に nil を返します。したがって、PDFKitten は PDF データの処理中にフラグメント全体をドロップします。

一見すると、関連するコード部分は現在のコード ベースでも同じです。/Encoding /WinAnsiEncodingしたがって、 `/Mac*Encoding' を使用するフォントの文字コード > 127 に関する問題を PDFKitten サイトで報告することをお勧めします。

于 2013-01-21T12:09:05.347 に答える