我正在尝试使用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
答案 0 :(得分:1)
不同之处在于:检查预先存在的PDF 时获得的页面树的深度为3,而在使用pdfBox创建 PDF 时形成的树为1
PDF规范ISO 32000-1允许页面树的任意深度和复杂性,参见第7.7.3节页面树。
在您的情况下,PDFBox选择最简单的结构,直接位于根节点下的所有页面,而预先存在的PDF 的制作者选择了更大的复杂性。
页面树的结构可能是由于不同的原因,
规范明确提到优化页面访问和可继承属性作为使用非平面树的原因。它确实不劝阻,更不用说出于其他原因禁止使用它们了。
OP没有共享预先存在的PDF ,因此我无法更加证实为什么该特定文档使用的内容不是像PDFBox这样的平面树。
但最终它并不重要。 PDF消费程序必须与任何合理的页面树结构相处并可能随意操纵它。
当然,如果一页PDF的页面树有一百万个节点深,那么就没有理由抱怨这个PDF没有例如显示与页面树深度为1的等效文档一样快。
编辑 OP同时共享预先存在的PDF 。根节点具有5个子节点,每个子节点还具有5个(或者在最后一个的情况下为6个)子节点,这些子节点是页面节点。没有继承的属性。
这看起来像是尝试创建一个平衡树来优化访问。考虑到文档大小(26页),这似乎没有必要。生产者很可能具有创建这些平衡树以优化大型文档的功能,并且也可以在此处使用此功能。
另一方面,PDFBox不会创建这样的平衡树,而是创建一棵平面树。