【发布时间】:2016-05-09 18:54:53
【问题描述】:
我正在尝试将各种 PDF 剥离。它们不是那么重的文字,偶尔会有图像。例如,我有两个 PDF,1.4Mb 和 740kb - 当我将它们组合在一起时,它们会膨胀到 6Mb!
我尝试了脚本组合和手动附加,结果相同,所以我猜这是一个潜在的问题。对它为什么发生的一些解释会很有用,所以我可以看看避免它的方法。是不是颜色模型不匹配?它们的字体很小。
【问题讨论】:
-
你用什么方法来组合它们?
我正在尝试将各种 PDF 剥离。它们不是那么重的文字,偶尔会有图像。例如,我有两个 PDF,1.4Mb 和 740kb - 当我将它们组合在一起时,它们会膨胀到 6Mb!
我尝试了脚本组合和手动附加,结果相同,所以我猜这是一个潜在的问题。对它为什么发生的一些解释会很有用,所以我可以看看避免它的方法。是不是颜色模型不匹配?它们的字体很小。
【问题讨论】:
你没有告诉我们你是如何组合 PDF 的,这让你的问题变得相当理论化,所以我会给你一个理论上的答案:
如果您将此 PDF“分解”为 10 个单独的单页 PDF,则每个 PDF 将包含大约 300 KB:内容流中的 100 KB + 资源中的 200 KB(我忽略了拥有 10 个单独的外部参照表的开销和文件预告片)。
如果您使用 iText 合并 PDF,那么使用 PdfCopy 将生成 3000 KB 的 PDF,因为 PdfCopy 只是尽可能快地复制文档而不查看文档的内容。如果您想要 1200 KB 的 PDF,则需要使用 PdfSmartCopy,在这种情况下,您将需要更多的内存和 CPU,因为 iText 将检查每个 PDF 并重用原本多余的对象。
在您的问题中,您提到您有一个 1.4Mb 和一个 740kb 的 PDF,而 1.4Mb + 740kb 的 PDF 为 6Mb。我的理论示例的第一部分没有解释规模的极端增长,所以这里是第二部分。
假设您的原始 PDF 具有压缩的对象流和压缩的交叉引用表。假设您将这些 PDF 组合成一个更像 PDF 1.4 文档的 PDF。在这种情况下,压缩的对象和压缩的交叉引用流将不再被压缩,从而导致文件更大。
可能还有其他原因,具体取决于原始 PDF 的性质以及您用于合并 PDF 的工具。如果以上都不适用,您应该澄清。
【讨论】: