ITextPdf PdfWriter.getPageNumber（）返回一个额外的页码

Question

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

• getPageNumber（）是否确实一直为页数增加1？
• 我可以获得更多这方面的见解吗？ （我们正在使用iText 5.5.6）

发生这种情况时的上下文是在页面事件的getClass()方法中使用getPageNumber()以获取总页数。在这种情况下，返回的值超过了数字。

Answer 1

这个答案仅适用于iText 5; iText 7使用完全不同的方法。

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

因此，当您在getPageNumber()方法中使用onCloseDocument()方法时，需要减去一页。

这种奇怪行为只有一个原因： iText有机增长，和PDF创建过程（＆＃34; 5步骤＆＃34;）早于页面事件。我们没有考虑在最初设计iText时添加页面事件。页面事件被固定在原始设计上，并产生了一些后果，例如＆＃34;问题＆＃34;你在问题中提到。

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