iText7:PdfDictionary过早发布

Question

对于某些PDF，我在刷新标记结构时看到一个NPE。这个问题发生在iText 7.0.2-Snapshot中。iText 5.5.10可以很好地处理这些文件。NPE在pdfdictionary.get（PdfName键，布尔asDirect)中抛出，因为映射是空的。该类中的映射只有在调用releaseContent()时才能变为null。

因为releaseContent()的唯一目的是--就我所知--释放内存，所以我测试了当它更改为空方法时会发生什么。结果是文件似乎正常处理。不再有例外。下面是一个示例文件。

protected void releaseContent() {
    List<Integer> objs = Arrays.asList(6888, 6856, 6824, 844, 836);
    if (objs.contains(indirectReference.objNr)) {
        return;
    }
    map = null;
}

PdfReader reader = new PdfReader(src);
PdfWriter writer = new PdfWriter(dest);
PdfDocument doc = new PdfDocument(reader, writer);
doc.close();`

输出是什么：

Exception in thread "main" com.itextpdf.kernel.PdfException: Tag structure flushing failed: it might be corrupted.
at       com.itextpdf.kernel.pdf.PdfDocument.tryFlushTagStructure(PdfDocument.java:1746)
at com.itextpdf.kernel.pdf.PdfDocument.close(PdfDocument.java:727)
at perinorm.cleanPdf.MainCleanPDF.run(MainCleanPDF.java:139)
at perinorm.cleanPdf.MainCleanPDF.lambda$2(MainCleanPDF.java:58)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(Unknown Source)
at java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
at java.util.stream.ReferencePipeline$2$1.accept(Unknown Source)
at java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
at java.util.Iterator.forEachRemaining(Unknown Source)
at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Unknown Source)
at java.util.stream.AbstractPipeline.copyInto(Unknown Source)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.ReferencePipeline.forEach(Unknown Source)
at perinorm.cleanPdf.Main.main(Main.java:56)

Caused by: java.lang.NullPointerException
at com.itextpdf.kernel.pdf.PdfDictionary.get(PdfDictionary.java:555)
at com.itextpdf.kernel.pdf.PdfDictionary.get(PdfDictionary.java:146)
at com.itextpdf.kernel.pdf.tagging.PdfStructElem.getK(PdfStructElem.java:338)
at com.itextpdf.kernel.pdf.tagging.PdfStructElem.getKids(PdfStructElem.java:322)
at com.itextpdf.kernel.pdf.tagging.PdfStructTreeRoot.flushAllKids(PdfStructTreeRoot.java:247)
at com.itextpdf.kernel.pdf.tagging.PdfStructTreeRoot.flushAllKids(PdfStructTreeRoot.java:249)
at com.itextpdf.kernel.pdf.tagging.PdfStructTreeRoot.flushAllKids(PdfStructTreeRoot.java:249)
at com.itextpdf.kernel.pdf.tagging.PdfStructTreeRoot.flushAllKids(PdfStructTreeRoot.java:249)
at com.itextpdf.kernel.pdf.tagging.PdfStructTreeRoot.flushAllKids(PdfStructTreeRoot.java:249)
at com.itextpdf.kernel.pdf.tagging.PdfStructTreeRoot.flushAllKids(PdfStructTreeRoot.java:249)
at com.itextpdf.kernel.pdf.tagging.PdfStructTreeRoot.flush(PdfStructTreeRoot.java:184)
at com.itextpdf.kernel.pdf.PdfDocument.tryFlushTagStructure(PdfDocument.java:1744)
... 16 more

Answer 1

这个问题的直接原因是，在示例文档的结构树中，一些节点被多次使用，例如。

6770 0 obj
<<
  /K [ 6873 0 R 6874 0 R 6875 0 R 6876 0 R 6877 0 R 6878 0 R 6879 0 R
       6880 0 R 6881 0 R 6882 0 R 6883 0 R 6884 0 R 6885 0 R 6886 0 R
       6887 0 R 6888 0 R 6888 0 R ]
  /P 5874 0 R
  /S /TR    
>>

如您所见，68880R在此结构树节点的子节点数组中出现了两次。

当iText 7关闭pdfdocument时，它遍历结构树并将找到的每个元素刷新到目标文档：

private void flushAllKids(IPdfStructElem elem) {
    for (IPdfStructElem kid : elem.getKids()) {
        if (kid instanceof PdfStructElem) {
            flushAllKids(kid);
            ((PdfStructElem) kid).flush();
        }
    }
}

private void flushAllKids(IPdfStructElem elem) {
    for (IPdfStructElem kid : elem.getKids()) {
        if (kid instanceof PdfStructElem) {
            if (!((PdfStructElem) kid).isFlushed())
            {
                flushAllKids(kid);
                ((PdfStructElem) kid).flush();
            }
        }
    }
}

通过此更改，示例文档将无例外地被盖章。