iText/iTextSharp中字体属性及字体替换对PDF生成大小的影响

嘿，很高兴能帮你理清这两个和iText/iTextSharp相关的PDF体积问题，我来给你详细拆解：

字体是影响PDF体积的核心因素之一，主要体现在这几个维度：

• 嵌入与否是关键：如果不嵌入字体，PDF只会记录字体名称，完全依赖阅读器本地的字体文件，体积会非常小；但如果嵌入字体，尤其是完整嵌入整个字体文件（少则几十KB，多则几MB），PDF体积会直接暴涨。iText默认会嵌入字体子集——只打包文档中实际用到的字符对应的字形数据，这样能大幅降低体积，但还是比不嵌入要大。
• 子集化的彻底程度：子集化提取的字符越少，嵌入的数据就越小。比如你只用到宋体的100个常用字，子集嵌入的字体大小肯定远小于用到几千个生僻字的情况。
• 字体本身的格式与体积：不同字体格式的体积差异很大，比如TrueType（.ttf）通常比OpenType（.otf）更紧凑，Type1字体在老版本PDF中体积优势更明显。另外，本身带压缩的字体（比如部分优化过的ttf）嵌入后也会让PDF更小。
• 字体对象的复用：如果文档中多次使用同一种字体（相同大小、粗细、颜色），只要你复用同一个Font对象，iText就只会嵌入一次字体数据；但如果每次都新建Font实例，可能会导致重复嵌入，无端增加体积。

你观察到付费软件替换字体后有差异，这种操作确实会直接影响PDF体积，核心变化集中在这几点：

• 嵌入字体的体积差异：如果原PDF嵌入了体积较大的商业字体子集，替换成本身更轻量化的开源字体（比如Noto系列、Roboto），哪怕同样做子集嵌入，新字体的字形数据可能更紧凑，体积会明显减小。反过来，如果替换成更复杂的装饰性字体，体积可能会增加。
• 是否取消字体嵌入：很多付费压缩工具的“字体优化”会偷偷把嵌入的字体换成系统通用字体（比如Windows的Arial、Mac的Helvetica），然后取消嵌入，只保留字体名称。这种操作会让PDF体积大幅缩水，但代价是在没有对应系统字体的设备上显示会走样——这也是你看到字体略有差异的常见原因。
• 子集化的优化程度：原PDF的字体子集可能没做到最优（比如iText默认的子集化可能保留了少量冗余数据），付费工具替换时会重新做更彻底的子集化，只保留文档中绝对必要的字符数据，进一步压缩体积。
• 字体压缩算法的差异：不同工具对嵌入字体的压缩处理不一样，iText默认的压缩算法可能比较基础，而付费工具可能用了针对字体字形表的特殊压缩逻辑，哪怕替换的字体类型类似，最终嵌入的体积也会更小。

如果你想在自己的iTextSharp工具里实现类似的字体优化，可以试试这几个方向：强制对嵌入字体做子集化、替换为版权合规的轻量开源字体、检查代码中是否重复创建相同字体对象并统一复用。

内容的提问来源于stack exchange，提问作者Victor