iText7 .NET RegisterSystemDirectories与其他字体方法差异咨询

核心问题与观测结论 #

• 开发过程中需要明确PdfFontFactory.RegisterSystemDirectories()与其余4类字体调用方法的行为差异
• 实测验证：调用PdfFontFactory.GetRegisteredFonts()获取已注册字体列表时，仅PdfFontFactory.CreateRegisteredFont("calibri", PdfEncodings.IDENTITY_H, True)的调用会对结果产生影响，其余方法均不会改变返回的注册列表
• 异常定位：RegisterSystemDirectories()会触发系统字体全量扫描，带来500MB级别的额外内存占用，是偶发OutOfMemoryException的根因
• 业务刚需：仅需要使用指定字体家族——arial、calibri、comic、georgia、lucida、segoe、times、trebuchet、verdana、consola，无需加载系统全部字体
• 异常场景：未对上述指定字体做预注册时，向PdfDocument添加使用对应字体的段落，会抛出Invalid font type异常

各字体处理方法的行为差异 #

结合实际测试结果，不同方法的作用层级与生效范围完全独立：

• PdfFontFactory.RegisterSystemDirectories()
  属于iText上层PDF字体工厂的批量注册能力，会递归扫描所有操作系统默认字体目录，把扫描到的全部字体元数据加载到PdfFontFactory的全局注册缓存中，全量加载的特性是内存占用过高的直接原因
• PdfFontFactory.CreateRegisteredFont("calibri", PdfEncodings.IDENTITY_H, True)
  跨层级完成两个动作：一是按指定编码、字体嵌入规则直接实例化可用于PDF写入的PdfFont对象；二是将该字体以"calibri"为标识写入PdfFontFactory的全局注册字典，因此是唯一会改变上层已注册字体列表的调用
• PdfFontFactory.RegisterDirectory("C:\Windows\Fonts\Calibri")
  设计上属于上层PdfFontFactory的目录注册方法，理论上扫描到的字体应同步到注册字典；但实际测试中调用后注册列表无变化，原因是Windows系统默认字体存储不存在Calibri单独子目录，路径下没有可被iText识别的字体文件，扫描流程无有效结果可写入
• FontProgramFactory.RegisterFontDirectory("C:\Windows\Fonts\Calibri")
  属于iText底层字体解析层的注册逻辑，所有扫描结果只会写入底层FontProgram的解析缓存，不会向上层PdfFontFactory的注册字典同步，因此上层的GetRegisteredFonts()无法感知到这些注册内容，对返回结果无影响
• FontProgramFactory.CreateRegisteredFont("calibri")
  同样是底层字体解析层的方法，仅能从底层缓存中检索已加载的字体程序，不会向上层注册字典写入任何内容，因此也不会改变上层的已注册字体列表

指定字体轻量化注册方案 #

完全可以绕开RegisterSystemDirectories()的全量扫描逻辑，仅注册业务需要的指定字体家族，把额外内存占用从500MB降低到10MB以内，同时规避Invalid font type异常：

1. 针对需要的字体家族，逐一匹配Windows系统默认存储路径下对应的字体文件完整路径，无需递归扫描整个系统字体目录
2. 逐一对每个字体文件调用PdfFontFactory.RegisterFont(字体文件完整路径, PdfEncodings.IDENTITY_H)方法，把指定字体直接注册到上层PdfFontFactory的缓存中
3. 注册完成后通过PdfFontFactory.GetRegisteredFonts()校验结果，确认所有需要的字体已被正常加载
4. 后续创建使用这些字体的段落时，iText会直接从缓存中检索匹配字体，既不会抛出字体类型错误，也不会因全量扫描带来不必要的内存开销

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