直接用FreeType生成的SDF字体发虚或锯齿，是因为FT_Render_Glyph输出位图而非真SDF；radius过小导致梯度不足，且未设FT_LOAD_NO_BITMAP会fallback到位图覆盖SDF；需用矢量轮廓离线生成SDF，纹理用非sRGB格式，shader中正确采样并用fwidth计算edge。
为什么直接用 FreeType 生成的 SDF 字体在 C++ UI 中看起来发虚或边缘锯齿？
因为标准 FreeType 的 FT_Render_Glyph 输出的是位图（bitmap），不是真 SDF；若手动用距离场算法（如 Solomon’s 8SSE）离线生成 SDF，但采样半径（radius）设得太小（如 2–4 像素），会导致放大时梯度信息不足，GLSL 中的 smoothstep 插值失去依据，视觉上就是“糊”或“亮边”。更隐蔽的问题是：FreeType 加载时未启用 FT_LOAD_NO_BITMAP，导致 fallback 到 hinting 后的位图，覆盖了你精心生成的 SDF 纹理。
- 务必用矢量轮廓（
FT_LOAD_NO_BITMAP | FT_LOAD_NO_HINTING）提取 glyph outline，再喂给离线 SDF 工具 - SDF 图谱分辨率建议 ≥ 512×512（单字平均 ≥ 64×64），
radius至少设为字体大小的 1/6（例如 48pt 字设radius=8） - 生成后用图像查看器放大检查：SDF 纹理中字符主体应是接近 0.5 的灰度，边缘过渡区需有平滑渐变（不是硬阶跃）
如何让 OpenGL / Vulkan UI 渲染器正确采样 SDF 纹理并避免 gamma 错乱？
SDF 渲染依赖纹理采样值与屏幕空间距离的线性映射，而默认纹理格式（如 GL_R8）和 sRGB 启用状态会破坏这个映射。常见错误是把 SDF 纹理绑定到 sRGB 格式的 texture unit，导致硬件自动做 gamma 解码，把 0.5 变成 ~0.73，fwidth() 计算出的 anti-alias 范围就偏大，文字发虚。
- 创建纹理时显式指定非 sRGB 格式：
GL_R8（OpenGL）或VK_FORMAT_R8_UNORM（Vulkan），禁用GL_TEXTURE_SRGB_DECODE_ARB - 片段着色器中必须用线性采样：
texture(sdfTex, uv).r，不能加texelFetch或整数坐标 - 关键公式别硬编码：
float sd = texture(sdfTex, uv).r; float alpha = smoothstep(0.5 - edge, 0.5 + edge, sd);，其中edge = fwidth(sd) * 0.5;—— 这个fwidth必须作用于原始采样值，不能是变换后的
如何在 C++ UI 框架（如 Nuklear、Dear ImGui）中注入自定义 SDF 渲染逻辑？
多数轻量 UI 库只暴露 draw_list 或 push_texture 接口，不提供字体栅格化钩子。强行 patch nk_font_atlas_add_from_file 或 ImFontAtlas::AddFontFromFileTTF 很危险，因为它们内部会调用 stb_truetype 并覆盖你预生成的 SDF 数据。
- 绕过内置字体系统：用
nk_user_font或ImFontAtlasCustomRect手动注册 SDF 字形区域，把每个字的 UV 和 advance 写死进结构体 - 渲染时禁用 UI 库的文本绘制，改用自定义
nk_draw_list_add_text替代函数，传入你的 SDF texture id 和字形 UV 数组 - 注意 DPI 缩放：SDF 的
edge值需乘以io.FontGlobalScale（ImGui）或ctx->style.font->height（Nuklear）做归一化，否则高 DPI 屏幕下描边过粗
离线 SDF 生成时容易被忽略的字符集与 kerning 问题
很多 SDF 工具（如 msdfgen）默认只处理 ASCII，但中文 UI 需要 GBK/UTF-8 覆盖 2W+ 字符；若批量生成时没按 Unicode 区块分批处理，内存会爆，且输出纹理 atlas 无法对齐。更麻烦的是 kerning 对 SDF 无效——SDF 本身不存字距，必须在布局阶段用原始 TTF 的 FT_Get_Kerning 查表补偿，否则 “AV”、“To” 这类组合会留白过大。
立即学习“C++免费学习笔记（深入）”；
- 用
ftview或fonttools先确认 TTF 是否含GPOS表，再用 FreeType 的FT_HAS_KERNING(face)判断运行时是否可用 - 生成 SDF atlas 前，先用脚本提取所有目标字符的
FT_Load_Charbbox 和FT_Get_Kerning偏移，写入 JSON 供 C++ 运行时查表 - 避免把全量汉字塞进一张纹理：按使用频率分 tier（常用 2000 字 → 1024×1024，次常用 → 单独 atlas），运行时按需 bind
真正卡住人的往往不是 SDF 生成算法，而是 FreeType 的加载模式、纹理格式的隐式转换、以及 UI 框架对字体数据流的强耦合。调通前先用 RenderDoc 抓一帧，看传给 shader 的纹理内容是否真的是你生成的灰度图，而不是某处悄悄 fallback 出来的位图。
