iText的使用LocationTextLocationStrategy“坐标超出允许范围的”异常(

例外“坐标超出允许的范围内”被抛出时，我尝试使用LocationTextExtractionStrategy 。

for (int pageNum = 1; pageNum <= document.getNumberOfPages(); pageNum++)
{
    PdfPage page = document.getPage(pageNum);
    sb.append(PdfTextExtractor.getTextFromPage(page, new LocationTextExtractionStrategy()));
}

关于异常的更多信息：

java.lang.IllegalStateException: Coordinate outside allowed range

    at com.itextpdf.kernel.pdf.canvas.parser.clipper.ClipperBase.rangeTest(ClipperBase.java:76)

我有相同的软件产生的2个类似的PDF文件，在第一个抛出异常，第二没有。

PDF 1（例外）

PDF 2（OK）

什么是第一PDF抛出此异常？我该如何解决这个问题，而无需使用SimpleTextExtractionStrategy？

（根据您的堆栈跟踪您正在使用的iText 7 *版本。我相应地更新你的问题标签和复制与当前的iText 7.1.2-SNAPSHOT的问题。）

什么是第一PDF抛出此异常？

简而言之

无论您的PDF包含用于定义剪辑路径极端y坐标（超出ISO 32000-1实现限制），您的PDF 1仅仅是两次极端的PDF 2和iText的剪辑路径程序开始在两者之间hickup'ing。

详细

第1页PDF 1主要的页面内容流看起来是这样的：

q
[...]
% modifyCTM
0.802969 0 0 -0.802969 0 842 cm
[...]
q
0 0 741 98417 re W n
[...]
Q
q
0 0 741 98417 re W n
[...]
Q
q
0 0 741 98417 re W n
[...]
Q
q
0 0 741 98417 re W n
[...]
Q
q
0 0 741 98417 re W n
[...]
Q
q
0 0 741 98417 re W n
[...]
Q
Q

因此，即使考虑到CTM的初始修改您六倍定义剪辑路径与矩形的高度98417 * 0.802969这等于大约默认用户单元79026默认用户单元。

ISO 32000-1附件C.2 架构的限制 ，另一方面指示

符合读者应该适应服从约束的PDF文件。
[...]
最小页面大小应为3×3个单位在默认用户空间; 最大的应该由14,400单位14,400。

因此，您的剪辑路径的矩形超过5倍，作为一个页面可以是一个符合读者的预期支持。必然符合的读者不必支持您的极端夹路径。

PDF 2内置同样，有问题的剪辑路径仅仅是41879 * 0.802969单位高，即约33628台，这仅仅是因为多为需要高一倍以上得到支持。对于一些原因的iText似乎仍然支持这一点。

我该如何解决这个问题，而无需使用SimpleTextExtractionStrategy？

您可以通过改变不断调整的iText 7 com.itextpdf.kernel.pdf.canvas.parser.clipper.ClipperBridge.floatMultiplier

/**
 * Since the clipper library uses integer coordinates, we should convert
 * our floating point numbers into fixed point numbers by multiplying by
 * this coefficient. Vary it to adjust the preciseness of the calculations.
 */
public static double floatMultiplier = Math.pow(10, 14);

您可以尝试如Math.pow(10, 10)这对我来说既文件的工作。

那有人说，ISO 32000-2似乎已经掉了这个特定的页面大小的限制，仅仅有更通用的限制加语句就像一个特定的设备上，并在特定的操作环境中运行总是有实际的限制特定的PDF处理器。

因此，@iText应该考虑当前限制是否是这样的实际限制或应放松。