Go x/image/font/opentype Hinting 设置为什么影响小字号形状

我第一次排查小字号文字发虚时，先怀疑字体文件或绘制坐标，最后发现真正变化的是 Hinting。它不是字体的粗体、斜体开关，而是告诉栅格化器：矢量字形的节点怎样对齐到有限的像素网格。字号越小，可用像素越少，这个选择对轮廓和笔画粗细的影响就越明显。

官方资料：https://pkg.go.dev/golang.org/x/image/font/opentype

这篇只讨论 golang.org/x/image/font/opentype 的 FaceOptions.Hinting。先固定同一字体、同一字号和同一 DPI，再比较三个选项，通常就能解释“代码没变、字形却变了”的现象。

结论是：小字号下出现形状差异并不一定是字体损坏，而是 Hinting 对字形节点进行不同程度的量化。先用 HintingNone 判断轮廓基线，再根据输出设备考虑 HintingVertical 或 HintingFull，不要把它和字体样式混在一起。

先确认 Hinting 改变的是字形节点量化

opentype.NewFace 接收 FaceOptions，其中 Size 是点数，DPI 是每英寸点数，Hinting 则选择如何量化矢量字体的字形节点。换句话说，同一个 TTF 或 OTF 文件，在这些参数不同的情况下，本来就可能得到不同的 font.Face。

小字号的关键在于“舍入空间”变小：一个曲线节点轻微移动，就可能让某一列像素从点亮变成不点亮；一条笔画也可能从两列变成一列。于是肉眼看到的是字形变窄、变粗、转角改变，甚至不同字符的视觉重量不再一致。这个现象属于栅格化决策，不应先归因于 Drawer 或字符串内容。

对照三个 Hinting 选项

font.Hinting 当前提供 HintingNone、HintingVertical 和 HintingFull 三个常量。官方文档只把它们定义为量化策略，不保证所有字体都支持 Hinting，所以选择时要把字体本身的支持情况也算进去。

表格里的“适合”是工程取舍，不是对某种字体的保证。尤其是中文字体或设计较复杂的字体，不能因为 HintingFull 名字更完整就默认它视觉上更好。

在 NewFace 中固定字号与 DPI

排查时我会先固定输入字体和绘制参数，只替换 Hinting。下面的示例使用包内字体字节，重点是创建三个独立的 font.Face；代码没有把它当作运行截图或渲染结果证明。

package main

import (
    "fmt"
    "log"

    "golang.org/x/image/font"
    "golang.org/x/image/font/gofont/goregular"
    "golang.org/x/image/font/opentype"
)

func main() {
    // 解析同一份字体数据，避免比较时混入字体文件差异。
    parsed, err := opentype.Parse(goregular.TTF)
    if err != nil {
        log.Fatal(err)
    }

    modes := []struct {
        name string
        mode font.Hinting
    }{
        {"none", font.HintingNone},
        {"vertical", font.HintingVertical},
        {"full", font.HintingFull},
    }
    for _, item := range modes {
        face, err := opentype.NewFace(parsed, &opentype.FaceOptions{
            Size:    10, // 小字号更容易显出像素量化的差异。
            DPI:     96, // 固定 DPI，避免把缩放变化误判成 Hinting 变化。
            Hinting: item.mode,
        })
        if err != nil {
            log.Printf("%s: %v", item.name, err)
            continue
        }
        // Face 可能持有缓存和掩码缓冲区，比较完成后及时释放。
        fmt.Printf("%s: %+v\n", item.name, face.Metrics())
        face.Close()
    }
}

这里的 Metrics() 只能作为布局信息的观察入口，不能替代实际视觉回归。真正要比较的是同一批字符在目标画布上的轮廓、笔画连续性和行间距；如果业务使用 font.Drawer，还要保证 Dot 的基线位置一致。

我会怎样定位“小字号变形”

1. 先把 Size、DPI、字体文件和基线固定，只切换 Hinting。
2. 同时比较大字号和问题字号。只有小字号明显变化时，优先检查像素网格量化，而不是重写文本布局。
3. 选一组包含直线、曲线、细笔画和容易混淆字符的样本，记录字形边界、advance 和肉眼可读性。
4. 确认字体是否支持 Hinting；官方文档明确提示并非所有字体都支持，因此不能把三种策略当成普遍有效的滤镜。

一个实用的回归表可以只保留四列：字号、DPI、Hinting、结果备注。这样能把“字形变了”和“画布缩放了”“基线变了”“字体换了”分开，不会被一次偶然的截图印象带偏。

迁移清单与常见问题

• 从默认配置改为显式 Hinting 前，先保存旧版本在目标字号下的样本。
• 不要把 Hinting 当成 Weight、Style 或 Stretch；这些是不同的字体属性。
• Face 不是并发安全对象，多个 goroutine 不要随意共享同一个 face。
• 字体来自不可信输入时，注意 opentype 包文档给出的安全边界：它没有针对恶意输入做加固。

HintingFull 一定比 HintingNone 清晰吗？

不一定。它们解决的是不同的栅格化取舍，最终效果还取决于字体、字号、DPI 和输出设备。先用固定条件比较，再决定哪种视觉结果适合你的产品。

为什么我改了 Hinting，Metrics 看起来却没变？

Metrics 描述的是 Face 的布局度量，而 Hinting 的差异可能首先出现在字形掩码的像素轮廓。应同时比较绘制结果和布局数据，不能只看一个指标。