我已经使用rdlc生成了pdf，然后使用iTextSharp pdfsmartcopy类将多个pdf文件合并到一个文档中。但是我的pdf大小很大，我想减小该pdf文件的大小。我尝试使用iTextSharp压缩它，但是无法压缩它。当我将pdf文件在线上传到ilivepdf.com进行压缩时，它会将21MB的文件压缩为1MB。
答案 0 :(得分：0)
通常，问题与嵌入式字体有关。
您会发现，PDF确实致力于完全按照您的方式保存文档。
为此，PDF库可以决定嵌入字体。您可以想象这只是将字体文件放入PDF文档中。
但是，这是棘手的部分。
PDF规范考虑到这可能会过大。 我的意思是，如果您仅使用西方语言中通常使用的50多个字符，则嵌入整个字体几乎没有意义。
因此，PDF支持一种称为“字体子设置”的功能。这意味着，不是嵌入整个字体，而是仅将实际使用的那些字符嵌入文档中。
那么合并这些文档时到底出了什么问题？
（我将跳过很多技术细节。）
为了区分完全嵌入的字体，系统字体还是嵌入的子集字体，iText会在每次嵌入字体时为您的字体生成一个新的字体名称。
因此，包含Times New Roman子集的文档中的资源中可能会有“ Times-AUHFDI”。
类似地，第二个文档（同样包含Times New Roman的子集）可能会将“ Times-VHUIEF”列为其资源之一。
我认为它只是添加了一个随机的6个字符的后缀。 （此处为前iText开发人员）
PdfSmartCopy必须决定如何处理这些资源。可悲的是，它不知道这些字体是否实际上相同。因此，它决定将这两个子集都嵌入到新文档中。
这是一个巨大的内存损失。 如果您有100个文档，而所有文档都使用相同字体的子集，则该子集将被嵌入100次。
您列出的另一个工具实际上可能会检查这些字体是否相同（如果相同，则仅将它们嵌入一次）。否则，其他工具可能根本不在乎那么多，并根据部分名称匹配假定它们是相同的。
当然，理想的解决方案是比较字体中的实际字符，以查看这两个子集是否可以合并。
但这会困难得多（并且可能会降低性能）。
您能做什么？
有12种从未嵌入的字体。假定它们存在于每个系统上（因此为什么它们从未被嵌入。）
如果您可以控制生成PDF文档的过程，则只需决定仅使用这些字体即可创建它们。
或者，您可以编写一个更聪明的PdfSmartCopy。您将需要研究字体的构建和存储方式，并进行前面提到的实际比较。
向iText寻求技术支持。如果有足够多的人请求此特定功能，则可以使用它。