未来文本 API

# 未来文本 API 来源：https://wiesmann.codiferes.net/wordpress/archives/41710 Codex Gigas 第505页——马太福音 Codex Gigas 第505页——马太福音（https://en.wikipedia.org/wiki/Codex_Gigas#/media/File:CodexGigas_505_Matthew.jpg） 在评论 Ian Hickson 的 UI 框架（https://software.hixie.ch/ui-frameworks）文档时，关于未来文本 API 的问题突然浮现。自最初的 Macintosh Toolbox 以来，你与文本交互的方式变化甚微：你提供一个字符串、一些属性（如字体、字号）以及一些样式位（粗体、斜体），然后你可以要求绘制字符串或仅仅测量其尺寸。因此，认为未来很长一段时间内情况会保持不变也是情有可原的。文本与文化紧密相连，而文化正在发生变迁，所以我认为文本处理将会改变。我并不声称自己知道会发生什么，我只能从自己有限的视角出发，提供一些可能的变化方向，请理解这些只是*可能性*。 ## 扩展字素簇 `` 🇨🇭 `` 文本 API 最可能的发展方向是迁移到扩展字素簇（Extended Grapheme Clusters）而非码位（Code-points）（https://wiesmann.codiferes.net/wordpress/archives/41500）。这可以避免框中 HTML 序列之类的问题。这在技术上是有效的，但毫无意义——它基本上只对瑞士国旗的一半施加了强调，浏览器也不知道如何渲染它：*🇨*🇭，结果得到一个破碎的国旗和一个斜体的 `C`。Swift 已经将字符串定义为字素簇的序列，我猜想其他语言和图形 API 也会效仿。 ## 字体特性 OpenType 系统支持许多特性：彩色字符、字体变体、连字、变体形式，但大多数字体并未使用这些特性。原因很简单：构建一个特性丰富的字体需要大量工作。结果是许多图形 API 并不暴露或利用这些特性。神经网络最早的应用之一实际上是字符识别。利用 AI 生成字体的工具已经非常普遍，迟早它们将能够生成特性丰富的字体。将 Codex Gigas（https://en.wikipedia.org/wiki/Codex_Gigas）转换成一个具有丰富特性（如带历史装饰的首字母、抄写缩写等）的字体，只是时间问题。随着特性丰富的字体变得越来越常见和廉价，两件事将变得更重要：访问这些特性的 API，以及使用这些特性的 UI 组件。 ## 特性内省 计算机排版的一个基本假设是，当你对某些文本应用一个属性（比如斜体）时，*某些事情*会发生——理想情况下文本会倾斜。这个假设对于像 *tiger* 或 *虎* 这样的文本是相当合理的，但对于表情符号 *🐅* 则不一定成立（或许也能成立？）。许多其他特性也是如此，比如颜色、标题大写。这意味着需要一个 API 来了解哪些属性实际上*起作用*。另一种方法是引入一层间接性，例如告诉你想要能够在蓝色背景上最大化对比度的字体属性。这正是原始 Web 所做的事情，像 `strong` 和强调这样的属性，旨在以渲染系统上最富表现力的方式呈现（例如在文本终端上高亮显示）。在 HTML 的情况下，这显然是失败的，但也许现在这种方法可以奏效。 ## 动态文本组件 UI 工具包通常有一个基本的文本元素，用于构建按钮或标题面板等控件。如今，大多数布局组件都很灵活，可以更改其边界框以适应布局，但文本元素通常只有行高和文本宽度，仅此而已。它们可以通过空白扩展，但不能收缩。当周围的其他 UI 元素都可以调整大小时，这显得相当静态。现在，你可以通过在字形之间添加间距并使空格更宽来增加一定的水平弹性，但这只是以更分布的方式添加空白。 macOS 上为数不多的特性丰富字体之一是 Zapfino，它包含字符变体，可用于水平扩展或收缩文本。下面是我名字的紧凑版本： [![Matthias [Zapfino, Compact]](https://wiesmann.codiferes.net/wordpress/wp-content/uploads/ZapfinoMatthiasCompact.png)](https://wiesmann.codiferes.net/wordpress/wp-content/uploads/ZapfinoMatthiasCompact.png) 下面是扩展版本，宽度多出 24 像素。 [![Matthias [Zapfino Extended]](https://wiesmann.codiferes.net/wordpress/wp-content/uploads/ZapfinoMatthiasExpanded.png)](https://wiesmann.codiferes.net/wordpress/wp-content/uploads/ZapfinoMatthiasExpanded.png) 当然，Zapfino 具有相当特殊的风格，我绝不会主张在 UI 控件中使用它，但其底层的排版特性适用于任何字体，包括严肃的 *grotesk* 字体，甚至表情符号。如果你考虑一个有两个孩子的家庭字形 🧑🧑🧒🧒，你可以有一个宽版本（所有人排成一排），或一个堆叠版本（孩子们在前面）。基本上，这意味着你可以设计一个文本组件，根据可用宽度（也许还有高度，通过切换上升部和下降部）来切换排版变体。 ## 子字形处理 人们很容易将文本视为由原子单元——字符、字形、字素簇——组成的序列。像连字、组合字符这样的特性模糊了这条界线。对用户来说，1⁄2 是 1/2 的紧凑表示，但在第二种情况下我可以将上面的数字涂成红色，而在第一种情况下则不能。如果你用 MathML 来写，就可以：12。当一个特性的存在取决于表示方式时，这绝不是一个好迹象。我们倾向于认为 `i` 字符上的点是它的一部分，但土耳其语言不同意。所以我可以将同一个字符写成由无点 i 和组合点组成的序列：ı̇，并将点涂成红色，至少在标记中可以做到。在撰写本文时，Chrome 只是以均匀的黑色渲染这个字符。 在阿拉伯语和希伯来语中，元音以变音符号的形式书写，称为 Niqqud 或 Harakat。在宗教或教育文本中，这些符号通常以不同颜色打印。页面布局系统支持这一特性，但网页工具不支持。 你可能会辩称这只是一个小众情况。然而，大多数汉字是复合字。森林的“林”字，其表意描述序列为 ⿰（从左到右）+ 木 + 木。目前，汉字的渲染组合并非由 Unicode 处理，而是由专门的库处理（如果处理的话）。如果你认为这种分解不适用于拉丁字符，那么让我介绍一下 CJK 单位符号。你可以将“米每秒平方”写成一个字符：m∕s2（`U+33A8`）。事实是，在每种情况下，你都可以在分解形式下对文本设置属性，但在组合形式下却不能，这令人烦恼（且不一致），尤其是当你遇到像“龖”这样复杂的字符时。 ## 旋转 Matthias 竖排书写是中国、日本和韩国以及可能许多其他地区的传统文本布局。这导致了不同的布局方法，也影响了硬件。我的小米手环屏幕分辨率为 192 × 490 像素，窄而宽。这种形状对于手表来说是有意义的，显示 CJK 文本没有问题，但拉丁文本的通知则有点奇怪。这意味着文本控件可以具有动态布局，根据布局约束（以及设备方向等）在水平和垂直对齐之间切换。竖排文本在西方排版中不那么常见，但我们都见过酒店或餐厅的竖排招牌，而我们的脑袋并没有爆炸。有趣的是，一些字形在竖排模式下会变形，例如在 CJK 文本中，括号会旋转 90°。国旗是另一种可以根据情况旋转 90° 的事物，前面描述的字形变体选择也可能发挥作用。 分数是旋转的一个特例：如果你考虑上面的半分数，三种表示形式 1⁄2、1/2 和 12 中的数字和分数条会移动，导致不同的高度/宽度权衡。基本上，在这个模型中，一段文本更接近一个布局组件，它显示一行（或一列）字形，而这些字形又可以根据布局进行调整。 ## 超本地化/个性化 文本在用户界面中的一个作用是表示某些数据的人类可读版本：日期、时间、测量值、位置等。这很快就会变得复杂，因为不同的人期望这些信息以不同的格式呈现，而文本呈现方式会根据语言、文化以及语法等令人头疼的因素而变化。为了避免这种情况，大多数用户界面使用一种刻意的方式来表达事物，例如不说 *您收到了 4 封电子邮件*，而会说类似 *收到的电子邮件：4* 这样的内容，这样可以绕过语法格和正确的复数处理等问题。 我认为 AI 会改变这一点。LLM 使用正常语言来表达这些事物，因此期望会改变，而处理语言格式化的复杂性可以通过 AI 来自动化。这意味着 API 可以提供工具，实例化一个文本组件来以自然语言显示某个值，并处理所有本地化和格式化方面，包括个性化、礼貌程度等，这样核物理学家可以获得以 ronabarns（https://en.wikipedia.org/wiki/Barn_(unit)）表示的面积。 如果一个 AI 可以生成一个格式化模板，它也可以生成更多。日期总是可以以多种长度格式化，从 *2025/11/1* 到 *Saturday the first of November 2025*，这当然可以推广，因为单位可以缩写（" 表示英寸）、数字可以简化（1⁄2 表示 50%），或者更改为规范表示，例如在法语中，世纪用罗马数字表示。 ## 复杂、动态的页面布局 Web 对页面布局做了一些奇怪的事情：一方面，Web 是一个无处不在的页面布局系统；另一方面，它又是一个相当平庸的系统，因为它从未真正为此设计过¹（https://wiesmann.codiferes.net/wordpress/archives/41710#footnote1），而且渲染器是如此复杂以至于实现极少。几年前，我曾写道，HTML 是新的 X11（https://wiesmann.codiferes.net/wordpress/archives/30897），意思是它无处不在但基本已死，只有少数实现，每个人都在更高级的 API 上进行编码。随着图形 API 的发展，它们迟早会发展到能够提供比嵌入网页（当前默认做法）更好的页面渲染体验。 一种看待这个问题的方式是，你希望能够使用 API 实现一个页面布局程序；另一种方式是，你希望有一个 API，你可以向它投掷一个节点图并要求它进行布局，因为这已经是你用来做 UI 布局的 API 了。区别在于，容器需要处理适当的布局规则、两端对齐和断词等功能，同时考虑到各种文本段可以改变其尺寸以获得更好的布局。容器还必须处理非线性部分、浮动图形和图像、摘录、注释以及 Ruby 注释（https://en.wikipedia.org/wiki/Ruby_character）。基本上，就像一个更好的 LaTeX，其中页面的每个部分都可能是动态的。 LLM 倾向于输出大量文本，它们应该能够提供额外的结构以及带外信息，因此能够渲染其输出的 API 将非常有价值。 --- ¹ 是的，我知道 CSS 用于书籍甚至杂志排版，但它在许多方面仍然不足。