ios - PDFKitten 在错误的位置突出显示

Question

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

如您在屏幕截图中所见，我搜索了字符串“in”，除了最后一个字符串外，它始终正确突出显示。我得到了一个更复杂的 PDF 文档，其中突出显示的“in”框有将近 40% 的错误。

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

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

我使用了来自 PDFKitten 的原始示例 PDF 文档作为我的屏幕截图。

Answer 1

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

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)”)期望其参数是字符标识符。

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

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

不过，这应该首先进行三重检查。也许一些 widthOfCharacter 实现(对于不同的字体类型有不同的实现)尽管有评论，但毕竟期望参数是一个 unicode 代码......

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