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

因此，如果 CID 和 unicode 字符代码不一致，则会确定错误的字符宽度，并且无法信任任何后续字符的位置。在本例中，/fi 连字的 CID 为 12，与其 Unicode 代码 0xfb01 有很大不同。

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

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

（抱歉，如果我在这里或那里使用了错误的词汇，我是一个“Java 人......:)”