为什么使用pdfBox创建PDF后得到的页面树不同？

Question

我正在尝试使用pdfBox 创建一个pdf document，下面提到了相同的代码段

 for(int j=0;j<26;j++)
         {
             PDPage page = new PDPage(PDPage.PAGE_SIZE_LETTER);
             document.addPage(page);
             PDPageContentStream content = new PDPageContentStream(document,page);
             content.setFont(font[j%15], 12);
             content.beginText();
             content.moveTextPositionByAmount(100, 700);
             content.drawString("PDF BOX TEXT CONTENT");
             content.endText();
             content.close();
             //generate data for first page

         }

我可以创建 pdf，但是我得到的页面树与我已经为 existing PDF file 获得的具有相同内容流的页面树不同，所以我无法理解为什么 pdfBox 的工作方式不同，而创建pdf文档？如果有人能在这方面有所启发，那将是一个很大的帮助。

区别在于： 我在检查 pre-existing PDF 时得到的页面树的深度为 3，而在使用 pdfBox 创建 PDF 时正在形成的树是 1 。所以，我添加的所有 26 个页面似乎都是我的页面树根的孩子得到。

以下是文件： 已有文件：https://www.dropbox.com/s/7o7nocg5g5o7qry/ABC.pdf 新文件：https://www.dropbox.com/s/uubs36tikqkl5w1/26ABC.pdf

Answer 1

不同之处在于：我在检查 预先存在的 PDF 时得到的页面树的深度为 3，而在使用 pdfBox 创建 PDF 时形成的树 为 1

PDF 规范ISO 32000-1 允许页面树的任意深度和复杂性，参见。第 7.7.3 节 页面树。

在您的情况下，PDFBox 选择了最简单的结构，所有页面都直接位于根节点下，而 预先存在的 PDF 的生产者选择了更复杂的结构。

页面树的结构可能是由于不同的原因，

• 为了简单起见，可能会创建一个扁平树（如 PDFBox 的情况）；
• 平衡树可能是在包含许多页面的文档中优化页面访问的结果；
• 内部节点也可以保存可继承的页面属性（例如媒体框）；这有助于简化最终页面节点；
• 将多个 PDF 合并为一个的程序也可以复制原始页面树并将其用作合并文档中的子树；结果可能看起来不太均匀；
• 处理现有 PDF 的程序可能会以自己喜欢的方式添加新页面，而现有页面则按照原始 PDF 制作者的偏好进行组织；结果可能看起来不是很均匀；
• 创建 PDF 的程序可能有自己的内部建模文档的方式，这反映在它们创建的结构中；
• ...

规范明确提到优化页面访问和可继承属性是使用非平​​面树的原因。不过，它确实不劝阻，更不用说出于其他原因禁止使用它们了。

OP 没有共享 预先存在的 PDF，因此我无法做出更充分的猜测，为什么该特定文档使用的不是像 PDFBox 这样的扁平树。

但最终这并不重要。 PDF 消费程序必须与任何合理的页面树结构相处，并且可以随意操作它。

当然，如果一页 PDF 的页面树有一百万个节点深，则没有理由抱怨此 PDF 没有，例如显示速度与页面树深度为 1 的等效文档一样快。

编辑 OP 同时分享了预先存在的 PDF。根节点有 5 个子节点，每个子节点也有 5 个（如果是最后一个，则为 6 个）子节点，它们是页面节点。没有继承的属性。

这看起来像是尝试创建平衡树以优化访问。考虑到文档大小（26 页），这似乎没有必要。生产者很可能具有创建这些平衡树以优化大型文档的功能，并且在这里也简单地使用了此功能。

另一方面，PDFBox 不会创建这种平衡的树，而是创建一个扁平的树。