2.9 KiB
2.9 KiB
第八章：准确性怎样影响性能设计
8.1 字符宽度不总能独立相加
字偶距 kerning 会让相邻字形距离发生变化；连字可能把多个字母组成一个字形；阿拉伯文字母还会随上下文改变形态。
所以 width('A') + width('V') 未必等于 width('AV')。一个词整体测得的宽度，也未必直接告诉你从词中间截断后每一行的正确宽度。
Pretext 的策略是测量完整分段，同时提前记录紧急断词所需的 advances，以及行首、行尾的修正信息。复杂性主要支付在准备阶段，布局阶段读取结果。
8.2 相同 Unicode 文本，各浏览器也可能不同
浏览器引擎在空白、标点、行边界与拆词等方面存在差异。Pretext 的 engine profile 选择对应扫描规则、拟合模式与容差，而不是仅靠一套理想化 Unicode 换行实现预测所有浏览器。
这份模型有已知缺口，尤其在特殊字体设置、窄到不常见的内容宽度、某些复杂文字与平台 bug 上。它的目标是匹配支持范围内的浏览器行为；“算法能给出一个结果”并不能证明所有浏览器都一定这样画。
8.3 “无 DOM”有需要说明的例外
layout() 本身不做 DOM 测量。准备阶段则可能：
- 读取
<html lang>，除非调用者通过setLocale()给出了语言。 - 在需要修正 emoji 宽度时，按字体使用 DOM span 探测。
- 缺少 OffscreenCanvas 时，创建不挂载的 Canvas 元素。
因此应理解成它避免了“每个文本块依赖 DOM 测量”的架构，而不是声称整个库绝对不会访问 DOM。worker 中缺少 emoji 探测条件，准确性也可能不同。
8.4 重新准备的条件
| 变化 | 通常怎样处理 |
|---|---|
| 只有宽度变化 | 复用 handle，重新 layout() |
| 只有调用者指定行高变化 | 复用 handle，传入新行高 |
| 文字、字体、字号、字距、whiteSpace、wordBreak 变化 | 重新 prepare() |
| 页面语言变化 | 重新准备；旧 handle 保留旧规则与宽度 |
| 先前测过后，目标字体才加载完成 | 清理缓存并重新准备，避免继续用回退字体数据 |
| macOS emoji 相关 DPR 变化 | 按 README 要求清理并重新准备含 emoji 文本 |
最终行为受字体、语言和 CSS 的共同约束。根目录 README 的 Caveats、PLATFORM_BUGS.md和 ENGINE_FOLLOWUPS.md是理解边界的重要入口。
本章检查：height = lineCount × lineHeight 是否能概括带任意大小图片的富文本？不能，图片或不同字体可能把某一行撑高，需要调用者处理行高模型。