问如何调整由rdlc和itextsharp生成的PDF大小

EN

通常，问题与嵌入式字体有关。

你看，PDF真的努力保存你的文档，就像你制作的一样。

为此，PDF库可以决定嵌入字体。您可以将其想象为简单地将字体文件放入PDF文档。

但是，这里来了棘手的部分。

PDF规范考虑到了这可能是过度杀伤力。我的意思是，如果您只使用西方语言中通常使用的50多个字符，嵌入整个字体就没有什么意义了。

所以PDF支持一种叫做“字体子设置”的特性。这意味着，文档中只嵌入实际使用的字符，而不是嵌入整个字体。

那么在合并这些文档时到底出了什么问题呢？

(我将跳过许多技术细节。)

为了区分完全嵌入字体、系统字体或子集嵌入字体，每当嵌入字体时，iText都会为您的字体生成一个新的字体名称。

因此，包含Times New Roman子集的文档在其资源中可能有"Times-AUHFDI“。

类似地，第二个文档(同样包含Times New Roman的子集)可能会列出"Times-VHUIEF“作为其资源之一。

我相信它只是添加了一个随机的6个字符的后缀。(此处为前iText开发人员)

PdfSmartCopy必须决定如何处理这些资源。不幸的是，它不知道这些字体是否相同。因此它决定将这两个子集都嵌入到新文档中。

这是一个巨大的内存损失。如果您有100个文档，所有文档都使用相同字体的子集，则该子集将被嵌入100次。

你列出的另一个工具可能会检查这些字体是否相同(如果是，只嵌入一次)。或者，另一个工具可能根本不关心那么多，并基于部分名称匹配假设它们是相同的。

理想的解决方案当然是比较字体中的实际字符，看看这两个子集是否可以合并。

但这将更加困难(并且可能会造成性能损失)。

你能做什么？

1. 有12种从未嵌入的字体。它们被认为存在于每个系统中(这就是为什么它们从来没有嵌入)。

如果您可以控制生成PDF文档的过程，您可以简单地决定只使用这些字体创建它们。

1. Alternatively你可以写一个更聪明的PdfSmartCopy。您需要查看字体是如何构建和存储的，并执行我前面提到的实际比较。

1. 在iText上寻求技术支持。如果有足够多的人请求此特定功能，您可能会获得它。