怎么用 Gdiplus
读取 TTC 文件里的单个字体
Windows GDI+ 原生不支持直接从 TTC 中提取指定字体实例，
GdipCreateFontFromCollection这类 API 根本不存在。你调用
PrivateFontCollection.AddFontFile加载一个 .ttc 文件时，它会把整个集合里所有字体都注册进去——但你无法控制“只加载第 2 个字体”或“跳过 Bold 变体”。这是最常被误解的点：不是“能读但要写额外逻辑”，而是“根本没提供按索引/名称选取子字体的公开接口”。
实操建议：
如果只是想让 WPF 或 WinForms 控件能用 TTC 里的字体，直接调用PrivateFontCollection.AddFontFile("xxx.ttc") 就够了；系统内部会解析并注册全部子字体，之后你可用 new Font("Arial Unicode MS", 12) 这种名字引用（前提是名字匹配）
若需确认 TTC 包含哪些字体名，必须自己解析 TTC 结构——靠 PrivateFontCollection是拿不到列表的 别在部署时假设用户已安装 TTC 中的字体；
AddFontFile的注册仅对当前进程有效，且不能跨 session 持久化
手动解析 TTC 文件头获取字体数量和偏移
TTC 文件本质是多个 TTF 的拼接，开头有固定结构：
ttcf签名、版本、字体数量，后跟一串偏移数组。你不需要完整实现 OpenType 解析，只需读前 12 字节就能拿到子字体个数和每个 TTF 的起始位置。
常见错误现象：用
FileStream直接读
byte[4]判断签名，却忽略字节序（TTC 头部用大端，而 x86 是小端）；结果把
0x74746366当成
"tfct"判定失败。
实操建议：
用BinaryReader配合
BitConverter.IsLittleEndian ? BitConverter.GetBytes(x).Reverse().ToArray() : ...处理四字节整数，或直接用
IPAddress.HostToNetworkOrder转换 TTC 版本目前只有 0x00010000 和 0x00020000 两种，遇到其他值说明不是合法 TTC 偏移数组起始位置 = 12 + 4 * fontCount，每个偏移是 uint32，指向对应 TTF 的第一个字节（即从该位置开始可当独立 TTF 流处理）
用 Stream
拆出单个 TTF 子流再喂给 PrivateFontCollection
拿到某个子字体的偏移和下一个偏移（或文件末尾），就能构造一个只包含该 TTF 的
MemoryStream或
SubArrayStream。这时候再调用
AddFontFile就等价于加载单个 TTF——绕过了 TTC 的“全量注册”限制。
使用场景：你有一个 TTC 含 Light / Regular / Bold 三版，但 UI 只允许用户选 Regular；或者你想预检某字体是否支持中文（查 cmap 表），但不想把所有变体都注册进进程。
实操建议：
别用File.OpenRead后反复
Seek—— 在某些网络路径或只读介质上会失败；优先用
File.ReadAllBytes加载全量再切片
PrivateFontCollection.AddFontFile接收的是路径，不是流；所以必须把子 TTF 写到临时文件，或改用
AddMemoryFont（注意：后者要求传入完整 TTF 字节数组，且不能释放内存） 调用
AddMemoryFont后，务必保留该字节数组引用，否则 GC 回收会导致后续
Font创建失败，错误信息是
"Object is not a valid Font"
WPF 中用 FontSource
加载 TTC 子字体更可控
WinForms 和 GDI+ 被动接受 TTC 全量注册，WPF 却提供了细粒度控制：
FontSource构造函数支持传入
Uri+
int index，直接定位 TTC 内第 N 个字体。这是目前唯一无需手动解析、也无需临时文件的原生方案。
性能影响：WPF 内部仍会读取整个 TTC 文件，但只解析指定索引的字体表（如 name、cmap、glyf），比全量注册轻量得多；且不会污染进程级字体缓存。
实操建议：
URI 格式必须为pack://application:,,,/Fonts/#FontName或
file:///C:/xxx.ttc#2（末尾
#2表示第 3 个字体，索引从 0 开始） 如果 TTC 中字体 name 表缺失或重复，
#0可能加载失败；此时 fallback 到手动解析 +
AddMemoryFontWPF 的
TextBlock.FontFamily支持这种 URI，但 WinForms 的
Label.Font不支持——别混用上下文
真正麻烦的从来不是“怎么读 TTC”，而是“怎么确定你要的那个字体到底在第几个位置、它的 name 字符串是否带空格或版本号、以及下游控件是否认这个 name”。这些细节不打日志根本看不出问题。
