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

我正在尝试使用

pdfBox

创建一个

pdf文档

，下面提到了用于该文档的代码段

 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

         }

for（int j=0；j
区别在于：我在检查预先存在的PDF时得到的页面树的深度为3，而在使用pdfBox创建PDF时形成的树的深度为1

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

在您的例子中，PDFBox选择最简单的结构，即直接在根节点下的所有页面，而预先存在的PDF的生产者选择了更复杂的结构

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


为了使事情简单，可以创建一个平面树（如PDFBox的情况）
平衡树可能是多页面文档中页面访问优化的结果
内部节点还可以保存可继承的页面属性（例如媒体框）；这有助于简化最终页面节点
将多个PDF合并为一个PDF的程序也可能复制原始页面树，并将其用作合并文档中的子树；结果可能不太一致
操纵现有PDF的程序可能会以其首选方式添加新页面，而现有页面的组织方式与原始PDF制作者的首选方式相同；结果可能也不太一致
创建PDF的程序可能有自己的内部文档建模方式，这些方式反映在它们创建的结构中


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

OP没有共享预先存在的PDF，因此我无法更确切地猜测为什么该特定文档使用的不是像PDFBox这样的平面树

但最终这并不重要。PDF消费程序必须适应任何合理的页面树结构，并可以随心所欲地对其进行操作

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

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

这看起来像是试图创建一个平衡树来优化访问。考虑到文档大小（26页），这似乎没有必要。最有可能的是，制作人具有创建这些平衡树来优化大型文档的功能，并在此处简单地使用此功能

另一方面，PDFBox不创建这样的平衡树，而是创建一个平面树。
PDFBox在创建pdf文档时工作方式不同，pdf格式允许多种方式对同一文档进行建模。因此，在分析pdf时，您必须考虑所有变体。也就是说，您忘记了解释实际的差异对你来说是个问题，你从这里的答案中真正期望得到什么。感谢mkl的建议。希望我的帖子现在是清晰的。页面树的深度在PDF规范中没有被禁止（）.PDF创建者可以随心所欲地将其复杂化。为什么还要为页面树操心呢？您不需要它来访问单个页面，只需使用document.getDocumentCatalog（）.getAllPages（）。谢谢，Tilman，但我只是对结构感到困惑，否则我会尝试使用您稍后提到的api。这是有用的信息！！我会查看更多详细信息。我已在后期编辑中附加了这两个文件。请查看并提供更多可能的信息。我将稍后查看。我稍后查看并编辑了答案gly.预先存在的PDF将其页面树组织为一个非平凡的平衡树（因此，它比PDFBox的平面结构更深）。对于页面非常多的文档而言，这可能是一个优势。但是，对于26页的文档而言，这几乎不是优势，可能更像是一个负担，很可能对任何符合PDF标准的用户都没有影响。