ITextPdf PdfWriter.getPageNumber() 返回一个额外的页码

Question

查看我组织内、互联网上的许多 Java 代码示例以及 iTextPdf 中的示例，有一种常见的模式是从返回的页数中减去 1，例如： numberOfPages = writer.getPageNumber() - 1; // writer 是 PdfWriter 类型 看起来 iTextPdf 考虑了潜在的下一页，无论它是否存在。这对我来说没有多大意义，但它确实有效。

• getPageNumber() 是否确实始终将页数加 1？
• 我能获得更多关于这个的见解吗？ （我们使用的是 iText 5.5.6）

发生这种情况的上下文是在页面事件的onCloseDocument() 方法中使用getPageNumber() 以获取页面总数。在这种情况下，返回的值比数字多一。

Answer 1

此答案仅适用于 iText 5； iText 7 使用了完全不同的方法。

• 当您在 iText 5 中关闭文档时，iText 总是调用newPage() 方法来完成文档中的最后一页。 newPage() 方法也会初始化一个新页面，但是由于关闭文档后无法添加任何内容，因此该新页面将是空的，并且永远不会出现在您的文档中（因为空白页面被忽略）。在初始化永远不会完全存在的新页面期间，页面计数加一。
• 在 iText 5 中关闭文档时，onCloseDocument() 方法是最后调用的方法之一。在使用newPage()方法之后调用，也就是：在页码加一之后。

所以当你在onCloseDocument()方法中使用getPageNumber()方法时，需要减去一页。

这种奇怪行为只有一个原因：iText 已经有机增长，而且 PDF 创建过程（“5 个步骤”）早于页面事件。最初设计 iText 时，我们没有考虑添加页面事件。页面事件被固定在原始设计上，这会产生一些后果，例如您在问题中提到的“问题”。

正如我们在 JavaOne 演讲“糟糕，我们破坏了我们的 API”中所解释的那样，我们决定在很长一段时间内不破坏 API，即使破坏 API 会导致更优雅和更少的怪癖，就像你提到的那样.在 iText 7 中，我们决定从头开始重写 iText（打破所有向后兼容性），以便不再存在这种奇怪的现象。