PDFKitten在错误的位置上突出显示

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

正如你在屏幕截图中看到的，我search了string“in”，除了最后一个string之外，它总是被正确地突出显示。 我有一个更复杂的PDF文档，其中突出显示的“in”框近40％是错误的。

我读了整个语法，并检查了问题跟踪器，但除了行高问题，我没有发现关于宽度计算。 目前我没有看到任何模式计算或可能是错误的，我希望也许别人有一个密切的问题，我的。

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

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

Answer 1

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

StringDetector中的appendPDFString在处理某些string数据时使用两个string：

// 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]; 

string中的stringWithPDFString将其参数的字符标识符序列转换为unicodestring。

因此，尽pipevariables的名称，cidString不是一个字符标识符序列，而是unicode字符。 尽pipe如此，它的条目被用作didScanCharacter的参数，它在Scanner中被实现以通过字符宽度来转发位置：在Font中使用该值作为widthOfCharacter的参数来确定字符宽度，并且该方法（根据注释“Width给定字符（CID）缩放到字体大小“）期望其参数是字符标识符。

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

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

不过，这应该先进行三重检查。 也许有些widthOfCharacter实现（对于不同的字体types有不同的实现），尽pipe有这个注释，但是这个实现毕竟是一个unicode代码。

（对不起，如果我在这里或那里使用错误的词汇，我是一个'爪哇人… :)）