Go x/image/font/opentype 字号不变为什么修改 DPI 后字形变大

这类现象通常不是 Size 失效，而是把“印刷/排版意义上的字号”和“输出设备上的像素密度”混成了一个参数。opentype.FaceOptions.Size 的单位是 point，DPI 表示每英寸包含多少个点；在字号不变时提高 DPI，NewFace 仍会得到更大的像素缩放比例，所以字形、行高和字距都会随之变大。

Size 不变，DPI 为什么仍会让字形变大

opentype 的 FaceOptions 把两个量分开定义：Size 是以 point 表示的字号，DPI 是 dots per inch，也就是输出分辨率。point 本身不是“屏幕上的一个像素”，所以同一个 16 point 字体放到 72 DPI 和 144 DPI 的输出环境里，所占像素数不会相同。

当前实现的 NewFace 会把 Size * DPI * 64 / 72 转成 26.6 fixed-point 缩放值。换句话说，Size 只保持不变并不能锁定像素高度；DPI 翻倍，缩放因子也会接近翻倍，之后得到的 Metrics、字形边界和前进量都会基于新的 scale 计算。

字号设定的是逻辑字号，opentype 包渲染字形时的实际像素尺寸会直接和 DPI 挂钩，DPI 调大的情况下即使传入的字号数值没变，最终绘制出来的字形像素宽高也会同步放大，这就是你看到字形变大的核心原因。

package main

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

func faceAtDPI(dpi float64) (font.Face, error) {
    // 先解析字体文件；示例使用模块内置字体，实际项目可替换为 TTF/OTF 字节。
    f, err := opentype.Parse(goregular.TTF)
    if err != nil {
        return nil, fmt.Errorf("parse font: %w", err)
    }

    // Size 固定为 16 point，DPI 改变的是输出尺度，而不是排版字号本身。
    return opentype.NewFace(f, &opentype.FaceOptions{
        Size:    16,
        DPI:     dpi,
        Hinting: font.HintingNone,
    })
}

因此，若目标是“无论输出 DPI 如何变化，屏幕上都保持约 16 像素高”，就不能把 Size: 16 当成像素字号。更直接的办法是先确定目标像素值，再按输出 DPI 反推 point 值：Size ≈ targetPixels × 72 ÷ DPI。这只是尺寸换算；字体自身的字面高度、hinting 和取整仍会影响最终像素边界。

先确认你比较的是字形大小，还是基线位置

修改 DPI 后，视觉上“变大”可能来自三种不同变化：字面轮廓确实扩大、行高和 ascent/descent 变大，或者绘制时的基线没有随画布尺寸调整。font.Face 提供了不同层次的观察点：Metrics 描述整套字体的行距，GlyphBounds 描述单个字形边界，GlyphAdvance 描述绘制后前进多少。

func describe(face font.Face, r rune) {
    // Metrics 观察行级尺寸；它不是某一个字符的像素截图。
    m := face.Metrics()
    bounds, advance, ok := face.GlyphBounds(r)
    if !ok {
        fmt.Printf("rune %q has no glyph\\n", r)
        return
    }

    // bounds 和 advance 使用 fixed.Int26_6，比较时先保留固定点语义。
    fmt.Printf("height=%v ascent=%v descent=%v\\n", m.Height, m.Ascent, m.Descent)
    fmt.Printf("bounds=%v advance=%v\\n", bounds, advance)
}

如果 Metrics.Height、Ascent、Descent 和 GlyphBounds 一起变大，原因大概率是 Face 的 scale 随 DPI 变化；如果这些量接近不变，只有画面位置变化，就应检查 Drawer.Dot、画布尺寸和裁剪矩形，而不是继续调字号。

固定点坐标也会影响你对“变大”的判断

font.Drawer.Dot 使用 fixed.Point26_6，一个整数像素被拆成 64 个子像素单位。DPI 改变后，字体的 scale 变了，但如果仍然把同一组整数坐标直接当成适配后的基线，字形可能同时发生放大、上移或被裁剪。

func drawAt(face font.Face, dst draw.Image, x, baseline int, text string) {
    d := font.Drawer{
        Dst:  dst,
        Src:  image.NewUniform(color.Black),
        Face: face,
        // 统一用 fixed.P 创建基线；不同 DPI 的画布需要同步调整布局坐标。
        Dot: fixed.P(x, baseline),
    }
    d.DrawString(text)
}

排查时至少保持四个条件一致：同一字体文件、同一 Hinting、同一画布缩放策略，以及相同的基线定位规则。尤其不要拿 72 DPI 的 200×80 画布和 144 DPI 的 200×80 画布直接比较；后者并没有给更高分辨率留下更多像素空间，放大的字形自然更容易碰到边界。

按输出目标选择 Size 和 DPI

最容易出错的配置是：字体 Face 使用了高 DPI，画布和布局仍沿用低 DPI 的像素常量。这样的结果不是 API 把字号“偷偷改了”，而是字体尺寸和输出坐标采用了两套尺度。把 DPI、画布宽高、边距、基线和换行宽度作为同一组配置传递，问题通常会清晰很多。

常见问题

把 DPI 改成 144，Size 还需要改吗？

如果你想保持相同的 point 字号并输出更高密度的图像，通常保持 Size 不变，同时按比例放大画布和布局尺寸。如果你想保持屏幕上的固定像素高度，就需要根据目标像素反推 Size。

为什么只改 DPI，字距也变了？

GlyphAdvance 也是基于 Face 的缩放值计算的，DPI 参与 scale 后，字符前进量会一起变化。不要只测单个字的宽度，要同时检查整行布局。

Hinting 能阻止 DPI 导致的放大吗？

不能。Hinting 负责矢量字形节点的量化方式，DPI 仍然决定 Face 的基础缩放。可以固定 Hinting 以便比较，但不能用它抵消 DPI 的尺度变化。

排查时应该优先打印什么？

先记录 Size、DPI、Hinting、画布尺寸和基线，再比较 Metrics、GlyphBounds、GlyphAdvance。这样能把参数变化、字体度量变化和坐标变化分开。