iText PDFSweep regexbasedcleanup策略在某些情况下不起作用

我正在尝试使用iText PDFSweep RegexBasedCleanupStrategy来编辑pdf中的一些单词，但是我只想编辑这个单词，而不想出现在其他单词中，例如。 我想把al写成一个单词，但我不想把al写成矿物。 因此，我将Regex中的单词boundary\b作为参数添加到RegexBasedCleanupStrategy中

  new RegexBasedCleanupStrategy("\\bal\\b")

但是，如果单词位于行尾，pdfAutoSweep.cleanUp将不起作用。

简而言之 此问题的原因是，将提取的文本块展平为单个字符串以应用正则表达式的例程没有为换行插入任何指示符。因此，在该字符串中，一行的最后一个字母紧接着下一行的第一个字母，这隐藏了单词边界。如果出现换行，可以通过在字符串中添加适当的字符来修复该行为

有问题的代码 将提取的文本块展平为单个字符串的例程是com.itextpdf.kernel.pdf.canvas.parser.listener包中的CharacterRenderInfo.mapStringList。如果仅存在水平间隙，此例程将插入空格字符，但如果存在垂直偏移，即换行符，则不会向生成字符串表示的StringBuilder添加任何额外内容：

如果chunk.sameLinelastChunk{ //仅当前一个字符串的尾随字符不是空格，而当前字符串的前导字符不是空格时，才插入空格 如果chunk.getLocation.isAtWordBoundarylastChunk.getLocation&&！chunk.getText.StartWith&&！chunk.getText.endsWith{ 某人加上“”； } indexMap.putsb.length，i； 某人；某人； }否则{ indexMap.putsb.length，i； 某人；某人； } 可能的解决办法 可以扩展上述代码以在换行时插入换行符：

if (chunk.sameLine(lastChunk)) {
    // we only insert a blank space if the trailing character of the previous string wasn't a space, and the leading character of the current string isn't a space
    if (chunk.getLocation().isAtWordBoundary(lastChunk.getLocation()) && !chunk.getText().startsWith(" ") && !chunk.getText().endsWith(" ")) {
        sb.append(' ');
    }
    indexMap.put(sb.length(), i);
    sb.append(chunk.getText());
} else {
    sb.append('\n');
    indexMap.put(sb.length(), i);
    sb.append(chunk.getText());
}

此CharacterRenderInfo.mapString方法仅从RegexBasedLocationExtractionStrategy方法getResultantLocations包com.itextpdf.kernel.pdf.canvas.parser.listener调用，并且仅用于上述任务，即应用相关正则表达式。因此，使它能够正确地识别单词边界不应该破坏任何东西，但实际上应该被视为一种修复方法

一个人可能会考虑为断线添加一个不同的字符，例如，如果一个不希望处理垂直间隙与水平间隙不同的话，一个简单的空间。因此，对于一般的修复，可以考虑使该字符成为策略的可设置属性。 版本

---

我使用iText 7.1.4-SNAPSHOT和PDFSweep 2.0.3-SNAPSHOT进行了测试。

A您声称pdfAutoSweep.cleanUp不起作用-这是什么意思？清理工作根本就没有修订吗？或者它是否编错了什么？B问题可能是正则表达式的解释问题。因此，我建议您添加标签。我的意思是，当单词位于行的末尾时，清理没有编辑任何内容。如果我想编辑的单词在中间，清理会正确地编辑它。好的，我确实可以很容易地重现这个问题。嗨，mkl，这个补丁在7.1.5快照中吗？这个补丁适用于这个问题；还有一点进一步的信息，看起来它也与转换后的pdf有关，我使用wkhtmltopdf将一个html转换为pdf，出现了问题，但是如果我使用其他软件转换，没有问题。它也与转换后的pdf有关-这很可能是，一些生成器在一行末尾显式地绘制了一个空格字符，而有些则没有。如果有这样一个空格字符，那么原始的itext代码已经匹配了行尾的单词边界。