iOS 27 Beta 2 苹方 VF,附技术分析

import Foundationimport CoreTextlet copiedFileURL = URL("...")let data = Data(contentsOf: copiedFileURL)assert(data != nil)assert(CTFontManagerCreateFontDescriptorsFromData(data as CFData) == nil)assert(CTFontManagerCreateFontDescriptorsFromURL(copiedFileURL as CFURL) == nil)

如果有幸确实拿到了 CTFont 实例，也不需要考虑 LSB 的值，CTFontCreatePathForGlyph 只返回规范后的轮廓。

let font = CTFontCreateWithFontDescriptor(..., ...)var gid = 4635 as CGGlyphvar width = 0 as CGFloatCTFontGetAdvancesForGlyphs(font, .horizontal, &gid, &width, 1)let path = CTFontCreatePathForGlyph(font, gid, nil)!

这里所谓规范化指将字形的 LSB point 定为 x = 0，然后按照字号/UPM 缩放。如果一定要说，LSB 在这里就等于实际字面的最小横坐标；但既然记录了整个路径，为什么还要再单独强调 LSB 呢？

特意在这里列出需要提取 UPM 值也显得非常可疑。PingFang UI 的原始 UPM 没有多大意义，因为系统为了跟西文匹配，放大了 UPM 来缩小字身。要确定正常的 UPM，一般要把汉字字身宽定为 1em，因此对于苹方来说，正好是 1000。然而 hvgl 支持浮点坐标，UPM 选用 1000 并不能完全准确地反映 PingFang UI 带小数的坐标值。说「unitsPerEm=1000 ：这是中文字形的标准设计单位，确保字形精度」就是不对了。

fontTools 没有从 JSON 生成 TTF 的功能，fontmake 也没有。

真正会大量使用 JSON 作为中间格式的是 OTFCC 和 FontLab (VFJ)。这里说「导出为 JSON 格式」，再「使用 fontTools 库生成标准 TTF 文件」，中间缺了真正关键的构建逻辑。

如果只是把 Swift 读出来的路径转存成 JSON，再在 Python 里读 JSON，那这几个 4 GB 大的文件很像是 AI 作出的决定。以及人类编写 Swift 或 Objective-C 时，CGPathElementType 是枚举类型，会直接使用具名成员，不会在意它的 raw value 是多少。要特意写出「type=0 → moveTo……」这种废话，就是 AI 最喜欢的掉书袋了。

另外，PingFang 和 SF 确实用的是二次曲线。但根本原因是 TT VF 处理起来更高效一些；CFF2 VF 太凌乱了。「二次贝塞尔曲线（qCurveTo） ：苹果字体内部使用二次曲线而非三次曲线」显得没头没脑的；二次曲线没有三次曲线有表现力，结合前文关于 UPM 的表述，这个时候又不说「确保字形精度」了。AI 掉书袋 +1。