PDFKitten强调错误的立场

Question

我正在使用PDFKitten在PDF文档中搜索字符串并突出显示结果。 FastPDFKit或任何其他商业图书馆是没有选择的，所以我坚持最接近我的要求。

正如您在屏幕截图中看到的，我搜索了字符串“in”，除了最后一个字符串外，它总是正确突出显示。我得到了一个更复杂的PDF文档，其中“in”的突出显示框几乎有40％错误。

我阅读了整个语法并检查了问题跟踪器，但除线高问题外，我没有发现宽度计算。目前我没有看到计算结果或可能出错的任何模式，我希望也许其他人有我的问题。

我目前的期望是在字体类或RenderingState.m中的某处计算坐标和字符宽度是错误的。该项目非常复杂，过去也许有人和PDFKitten有类似的问题。

我使用PDFKitten的原始样本PDF文档作为我的截图。

Answer 1

在计算字符标识符与其unicode字符代码不一致的字符宽度时，这可能是PDFKitten中的错误。

StringDetector中的

appendPDFString在处理一些字符串数据时使用两个字符串：

// 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的参数，它在Scanner中实现了按字符宽度转发位置：它使用value作为width中的widthOfCharacter参数来确定字符宽度，以及该方法（根据注释“Width”）给定字符（CID）缩放到fontsize“）期望其参数为字符标识符。

因此，如果CID和unicode字符代码不一致，则确定错误的字符宽度，并且不能信任任何后续字符的位置。在这种情况下，/ fi连字的CID为12，与Unicode代码0xfb01不同。

我建议增强PDFKitten以在StringDetector中定义didScanCID方法，其中appendPDFString应该在didScanCharacter旁边为每个处理过的字符转发其CID调用。然后，扫描仪应该使用这种新方法来计算转发光标的宽度。

不过，首先应该对此进行三重检查。也许有些widthOfCharacter实现（对于不同的字体类型有不同的实现）尽管注释期望参数毕竟是unicode代码...

（对不起，如果我在这里或那里使用了错误的词汇，我是'Java家伙... :)）