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

时间:2014-08-10 12:59:21

标签: pdf pdfbox

我正在尝试使用pdf document创建pdfBox,下面会提到相同的代码

 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获得的页面树不同,所以我无法理解为什么{{1}在创建pdf文档时工作方式不同?如果有人可以在这方面启发,那将是一个很大的帮助。

区别在于: 我在检查pdfBox时获得的页面树的深度为3,而在使用pre-existing PDF为1创建PDF时形成的树。因此,我添加的所有26个页面看起来都是孩子们的根我得到的页面树。

以下是文件: 预先存在的文件:https://www.dropbox.com/s/7o7nocg5g5o7qry/ABC.pdf 新文件:https://www.dropbox.com/s/uubs36tikqkl5w1/26ABC.pdf

1 个答案:

答案 0 :(得分: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不会创建这样的平衡树,而是创建一棵平面树。