PdfPage.flush()的行为

Question

PdfPage.flush(true)到底是做什么的？SmartMode (或任何其他设置)是否会影响行为？在许多情况下，我希望页面尽可能长时间保持可编辑状态，所以在document.close()之前，不要担心PDF文档是在内存中组装的。但是，当生成非常大的文件(数万个页面)时，内存就会变得有限。我天真地希望PdfPage.flush(true)会将内容流写入磁盘并释放内存，但调用flush(true)似乎只向磁盘写入了几个字节。

我想我的问题的更一般的版本是“我们如何有效地将许多文档合并成一个非常大的文档？(itext7)”，但由于对PDF规范本身不是很精通，我也想更好地了解实际发生了什么。

Answer 1

在布局对象上调用flush()时，会强制这些对象及其子对象将其内容绘制(==写入)到编写器的输出流中。当手动调用flush()时，您只看到几个字节被写入的原因是因为默认的Document构造函数已经通过重载相关构造函数将iText设置为积极刷新：

/**
 * Creates a document from a {@link PdfDocument} with a manually set {@link
 * PageSize}.
 *
 * @param pdfDoc   the in-memory representation of the PDF document
 * @param pageSize the page size
 */
public Document(PdfDocument pdfDoc, PageSize pageSize) {
    this(pdfDoc, pageSize, true);
}

/**
 * Creates a document from a {@link PdfDocument} with a manually set {@link
 * PageSize}.
 *
 * @param pdfDoc         the in-memory representation of the PDF document
 * @param pageSize       the page size
 * @param immediateFlush if true, write pages and page-related instructions
 *                       to the {@link PdfDocument} as soon as possible.
 */
public Document(PdfDocument pdfDoc, PageSize pageSize, boolean immediateFlush)

至于对一般问题的建议:确实没有某种iText函数或配置可以让整个过程变得更快、更高效，但在iText之外，您可以使用一些技巧：

1)分配更多的资源，这是显而易见的，而且往往是不可行的。

2)多阶段批量处理:步骤X将10 -文件合并为1，继续步骤X+1合并，一般1个大文件会分别小于10个文件，因为可能会重复使用字体、图片等资源。

3)在其他地方不需要它占用的资源时运行合并过程，例如，在晚上，在午餐时等。

编辑:至于为什么PdfPage#flush()只向内容流写入几个字节，这取决于输入文档，但它很可能指向一个刷新的页面，该页面要么主要是文本内容，要么是大量共享资源。只要页面包含以前复制过的资源，SmartMode就应该限制写入页面刷新的输出流的数量。