UnityTextMeshPro踩坑一则

本文系用户投稿，不代表机核网观点

本文含有AI生成，请注意甄别

⚠️ 未经作者授权禁止转载

一直以来我对字体以及Unity的TextMeshPro 组件都是一知半解的状态。前几天心血来潮优化字体的时候踩了一个新坑，特此记录一下。
《魔力喵吉克》开启Playtest了！欢迎试玩和反馈！非常感谢！
问题描述及排查
项目刚开始的时候，我使用的是思源字体(SourceHanSansSC-VF)，但是我发现这个字体的字非常非常的细，但是我没想太多，先凑合着用了。前几天我找到了新的思源字体(SourceHanSansCN)，包里有不同权重的otf文件，然后我主要使用的是Regular和Medium的字重。
然后问题就出现了：我发现一些很常见的字，比如"认"、"钱"这种，使用Medium的字体，会无法显示出来。
我在电脑上安装Medium的字体文件，并在Sketch里使用这个字体，字能够正确的显示出来(能确定是使用的字体的字，因为字形很统一)
Medium字体不适用动态字体，而是使用Font Asset Creator静态生成，之前显示不了的字就正确渲染出来了。
至此我大概猜到是Unity的问题。
问题分析
通过ChatGPT，我了解了原因(前提是ChatGPT没骗我)
🧩 根本原因：TMP 动态字体系统的字符索引解析问题（FreeType + Unity Bug）
你遇到的情况实际上是 TMP 的 **动态字形生成器**（基于 Unity 内嵌 FreeType 引擎)在解析某些思源字体 OTF 文件时，**没能正确读取字形索引表（CMap 表）**。

以思源黑体为例：
- 每个权重都是独立的 OTF 文件；
- Adobe 在导出时，为了减小文件体积，某些权重的 CMap 子表（Subtable）被压缩或使用 format 12 (segmented coverage)；
- Unity 运行时动态字体加载器使用的 FreeType 接口版本（Unity 2021~2023 通常是 2.10.x）对 format 12/14 子表解析不全；
- 导致动态查询 `GetGlyphIndex(0x8BA4)` 返回 0（未找到），TMP 就渲染成“□”。
所以，这不是你字体缺字，而是 Unity 运行时的 **FreeType CMap解析兼容性问题**。

✅ 为什么静态模式能找到？
当你用 **Font Asset Creator**（编辑器模式）手动生成时，  TMP 调用的是 UnityEditor 内部的字体导入流程，会完整读取字体表（`cmap`, `glyf`, `GSUB`, `GPOS`），  而不是动态模式下的简化接口。因此静态模式下能正确生成“认”。
第二个问题，就是之前我使用SourceHanSansSC-VF为什么只出现一个非常细的字体。首先需要了解什么是VF。
🎛 什么是 Variable Font (VF)
Variable Font 是 OpenType 1.8 引入的新特性，可以在一个字体文件里包含多个字重。  
例如：
- 思源黑体 VF 文件中包含 `wght` 轴（weight，字重轴），范围 200–900；
- 如果支持 VF 的软件（如 Sketch、Figma、Photoshop、Chrome）可以通过设置 `wght=700` 来渲染加粗效果；
- 但 Unity TMP（截至 Unity 2023.3 / TMP 3.2.0）**不支持动态调整这些轴参数**。
之前的问题，简单来说就是Unity的TMP不支持VF字体动态切换或生成不同字重，而默认只使用最细的字重。
解决方案
为了解决上述的问题，我目前的做法是使用中文字库(3000常用字)，Medium字体使用Font Asset Creator静态渲染出来。但是这样也有坑，有时候会有中文字库里没有的字使用，然后我需要修改字库，然后重新渲染。
未来我可能会找个更好看更有个性的中文字体，或者后续统一使用思源的Regular字体，并使用动态字体。