万「字」皆可「连」 (影片文案)

万「字」皆可「连」 (影片文案)

几年前[0],我的一位朋友正在为艺术节的剧本搜集素材,一天我碰巧看见了她打印出来的稿件……对于我的眼睛来说,打印稿看上去是这个样子的:

这太奇妙了

我于是向她询问这些奇妙的空距是怎么来的,对方答曰:

要是不加空格的话,这些字母就会粘在一起,看起来怪怪的。
你看,这个 ⟨f⟩把 ⟨i⟩ 的点都吞掉了。

先不讨论这种行为本身合理与否,在当时对方还不甚熟悉字体排印,排出这样的版面也无可厚非。(后来这位朋友喜欢上了等宽字体 Cascadia Code,我想这不是没有原因的 www

不难看出,我们的朋友估计是在试图防止「连字」出现在版面上。诸位在阅读排印完善的连续西文文本时,常常能发现连字的存在。之前在第0集中的介绍极为粗浅,远不能构成对这个概念的基本认识。然而在「万字皆可连」的今天,还有什么是不能被续写的呢?


顾名思义,「连字」就是连起来的文字,它的英文 ligature 也来自拉丁文的「连接」一词 ligātus。一般情况下,我们将由多个字形结合而成的一个字形称为连字。在拉丁文本中有许多由字母互相连接而构成的字形,但它们的来历不尽相同。这个大家族可以分为两大类:排印学连字typographic ligature正字法连字orthographic ligature。就从我们更熟悉的那一类说起吧。

诸位如果对字体排印学有所涉猎,一定不会对 kerning 这个词感到陌生。虽然它通常被翻译为「字偶间距调整」,但该词的转译并不稳定[1],在此暂且保持原状。今天我们只消敲敲键盘就能调节字母对的间距,但若把字体排印的历史向前拨、回到金属活字的时代,调节字母之间的空白就没那么简单了。

字体 Neutra Text Expert Book 的大写字母 S

在排印的时候,每个金属活字都会占据一个称为「字身框bounding box」的矩形空间。字身框的宽度包含这个活字字图glyph[2]的宽度与字图两侧的边空或留白宽度。这些经过精心设计的留白能在大部分情况下保证字与字的间距恰到好处。若是字母对的空隙太窄,我们可向其中加入适当宽度的铅空来调节;而两个字母的间距过大的问题就不好解决了。

没有使用 kerning 的 Perpetua 字体示例

如果每个活字的字图均被局限在字身框之内,一些字母之间就会形成多余的空隙。这些空白会打乱文本固有的节奏、误导读者的视线、使页面的灰度失衡——总之,这些诡异的空白降低了文本的可读性readability。为了规避这种情况,字体设计师们就让一些字母的字图突出字身框,也就是把一些活字的留白削减为负值。这些突出字身框的字母笔画叫作「kern」,带有突出部分的活字就顺理成章地叫作「kerned type」。没错,这便是「kerning」的词源所在。值得一提的是,GB/T 16964.1-1997 将「kern」称作「出界」,是个很直观的翻译

使用字体 Caslon 540 模拟带有 kern 的小写字母 f 活字
字体 Adobe Minion Pro Italic 如何处理单词 firefly?

然而 kerned type 很快便遇上了新的问题。以小写字母 f 为例,缩短的右留白使 ⟨f⟩ 的字头flag落在字身body的外缘,在排印时容易撞上后一个活字的字面,把 ⟨f⟩ 的升部ascender损坏掉。更有甚者,小写 ⟨i⟩ 和 ⟨l⟩ 的升部将会直接与字母 f 的字头发生冲突,根本无法并列放置。此时如果退而求其次、使用没有 kern 的 ⟨f⟩ 活字,先前提到的诡异空白就会在 ⟨f⟩ 的字头下出现。在使用拉丁字母的文本中,⟨fi⟩ 和 ⟨fl⟩ 字母对可是版面上的常客,如此处理并不美观。之后,一种优雅的解决方式应运而生:设计师们重新设计了一些字母对的造型,并把它们制成单独的活字。当这些活字转印到平面上时,一个个「排印学连字」就诞生了。这些连字不仅解决了前述空隙和碰撞的问题、让版面更整洁美观,还使得拣字与排版更加便利[3],使用连字也就在金属活字时代蔚然成风。在已经不存在实体活字的数字字体语境下,这些连字在美学上更直观的作用是防止没有必要的字图叠合,也就是防止难看的「黑块」出现。

字体 Ysabeau 的部分标准连字

排印学连字在用途上可以大略地归为两组。其一是改良文本视觉效果、优化阅读体验的「标准连字standard ligature」。在排印完善的文本中,一款字体的标准连字基本上都会被启用[4]当然,对于大多数简中出版社的西文部分,我们还是不要抱这种奢望了。值得注意的是,在先前的叙述中并没有强调一个排印学连字在外观上需要实打实将两个字母连起来。除了吃掉字母 i 的点点之外,字体设计师还可以把小写 ⟨f⟩ 的升部缩短,同时略微增加右留白来避免与接续的字符发生纠纷。只要一块字身上有多于一个字符,这些字符实际上也形成了一个排印学连字,尽管它们在外观上没有结合起来。在数字字体中,只要一些字符经由与连字相关的 OpenType 特性调用了一个字形替代自己时,这个被调用的字形也是个连字,无论其中的字母有没有相互连接的外观。这种「不连的连字」是仅仅在字体排印的技术语境下出现的特殊情况,我们讨论的连字仍然在视觉上连接在一起。

字体 EB Garamond:上方为标准连字,下方为自由连字
字体 Cambria 使用的「不连的连字」⟨fi⟩

其二是用来调整字母风格或增加装饰、为文本添彩的「自由连字discretionary ligature」或是「酌情连字」。相较于标准连字,自由连字的使用并非必要之举,但仍是优质正文字体不可或缺的一部分。由于这些连字大都来自手抄本中的连笔牵丝,自由连字在早期西文印刷品中的使用频率远高于今日,它们的使用也会为版面增添些许古雅气息。在今天的正文排版中,自由连字已经鲜少登场,但大小标题依旧是自由连字的用武之地。至于字标设计,那早已成为连字泛滥的重灾区了。

前面介绍的这些连字都属于「排印学连字」。之所以如此命名,是因为它们的功能只有在字体设计与字体排印上才得以体现,不会对其呈现的字母造成任何正字法上的影响。不会有人认为 ⟨fi⟩⟨Th⟩⟨st⟩ 连字是一个「字母」,使用连字的单词 first 也不会变成另一个词或者表达别的意义。换言之,这些连字没有正字法功能。同时,文本的正字法可以反过来作用它们的形成:一般来说,一个排印学连字是不能跨过语素边界形成的。在这种情况下,就算诸位使用的字体中包含一个 ⟨fffl⟩ 连字,它在德文的 Wasserstoffflasche 这个词里也派不上用场。

但对于另外一些字母连体兄弟或是姊妹们,情况就大不相同了。

在第 0 集中,我们曾提到了字母 W 的来历,它便是正字法连字的模范之一。尽管这个字母起源于两个 ⟨V⟩ 或两个 ⟨U⟩ 的连字,如今我们并不会认为 ⟨W⟩ 这个字符是由两个字母构成的,双 ⟨V⟩ 和双 ⟨U⟩ 也不能无端与这个货真价实的字母相互替换。同理,除非条件不允许,⟨AE⟩ 也不可随便替换冰岛、丹麦、挪威文字中的字母 ⟨Æ⟩,反之亦然。正字法连字是一个独立的语音与书写单位,而且改变了文本的正字法结构。它们已经转化为独立的字母,与原本构成它们的字母平起平坐。这一点也可以从很多正字法连字都同时拥有大写与小写形式上看出。当然,正字法连字并不具有字体排印上的功能,就像排印学连字也没法改变文本的正字法一样。至于附着在各种字母上的变音符号以及手写本中常见的简略记写形式,就是另外的故事了。

说到这里,需要先给诸位道个歉:我讲错了。在观看第 0 集时,诸位应该发现了其中的矛盾之一:虽然字母 ⟨ß⟩ 的名字是 ⟨S⟩ 加上 ⟨Z⟩,这个正字法连字却经常写成「长 s」(ſ) 与「圆 s」的连字,或一个像小写希腊字母 β 的符号。循其本源,真正的 ⟨ß⟩ 是在传统的德文书体 Blackletter 中成长起来的,而且一般以「长 s」与「有尾 z」(ʒ) 连字的形式出现在字面上。由于彼时的罗马体并不存在一个与这个连字完全等价的字符,⟨ß⟩ 在罗马体中也没能形成一个稳定的映射。

1903 年,莱比锡字体排印学会的声明(公有领域)

1903 年 7 月 9 日,莱比锡字体排印学会Typography Society of Leipzig宣发声明,并选用了一种名为「Sulzbacher 式」的字形作为 ⟨ß⟩ 的设计原则。尽管如此,「Sulzbacher 式」也并没有完全取代 ⟨ß⟩ 的其他兄弟姊妹,而是和 ⟨ſs⟩ 连字与 ⟨ſʒ⟩ 连字并驾齐驱。后者其实直接沿用了 Blackletter 的呈现形式;而在这个 ⟨ſs⟩ 的字形身上流淌着的却并非德意志的……呃……油墨。在德国语文之外,从手写的意大利书体Italic Script/Hand秘书手写体Secretary Script/Hand到印刷的罗马体与意大利体Italic Type,有一种 ⟨ſs⟩ 的字形已经流传许久。这个 ⟨ſs⟩ 连字神似我们今天看到的字母 ⟨ß⟩,但它当时只是个排印学连字。它之所以被引入罗马体德文,是因为中古高地德语的辅音流变:一开始,字母 Z 获得了 [s] 的发音;为了与原本读 [t͡s] 的 ⟨Z⟩ 区别,新读音便被改变拼写。之后在 13 世纪时,字母 S 也开始发 [z] 的音,音素 [s] 就由 ⟨ss⟩ 或 ⟨sz⟩ 来表记了。再后来的德文排字工使用罗马体排印德文时,「长 s」加「圆 s」作为一种 ⟨ss⟩ 的呈现形式,也就被自然地导入了德文。有意思的是,在 Blackletter 中还出现了 ⟨t⟩ 与 ⟨ʒ⟩ 的连字「tezett」(Ꜩ/ꜩ),后来也进入了罗马体文本中。这个连字甚至有两个 Unicode 码位 U+A728 U+A729,但它仍然只是一个排印学连字,并未转化为独立的字母。在 Blackletter 中还包含更多一家独有的排印学连字,在此就不一一列举了。

活字并非只有一面可供欣赏,我们同样可以从另一个视角观察并重新归类。在大众语境下的 Ligature 一词确实可以指代我们方才探讨的字符;但在更严格的定义下,「连字」ligature 指连写文种或「潜在连写文种」在连写过程中依理据形成的文字形式——注意三个采分点:文种、过程和理据。所谓「连写文种」,简单来说就是正字法上的同一个字母在词的不同位置上出现时具有不同写法的文种。先前提到的拉丁连字 ⟨fi⟩⟨st⟩⟨tʒ⟩ 、希腊连字 ⟨ϗ⟩ 、阿拉伯文连字 ⟨ﻻ⟩ 就属于这一类;另一个与之相对的概念是「合字」conjunct,一种非连写文种依理据形成、或是连写文种在非连写过程中依理据形成的文字形式。相比之下,作为一种将一般不会自发连接的字符相互连接的表现形式,conjunct 的形成有更多的主观因素介入:它缺少了字符之间连写的过程,而是直接将多个字符合为一体的。标准炼金术符号 ⟨🜇⟩⟨🝈⟩⟨🝫⟩、天城文合字 ⟨ज्ञ⟩⟨क्ष⟩ 以及我们熟习的「招财进宝」「孔孟好学」合字就是其中的典型。至于理据支援,试问在无理无据的情况下,我们又怎么能定义这些字符的显现形式呢?

承前所述,诸如 ⟨W⟩ ⟨Æ⟩ ⟨Œ⟩ ⟨ẞ⟩ 等都是起源于连字的字母——或曰正字法连字,这是毋庸置疑的。但这不代表正字法连字的领域内没有悬而未决的灰色地带。在荷兰文中有一个 ⟨ij⟩ 或是 ⟨ij⟩ 字母组合。尽管荷兰语联盟Dutch Language Union和相当多的词典认为这只是个由 ⟨i⟩ 和 ⟨j⟩ 构成的双字,但它的表现更像一个字母或是正字法连字:首字母大写时,整个 ⟨ij⟩ 都会被提升为大写;在专有名词缩写时,以 ⟨IJ⟩ 起首的词也会被缩写为「IJ.」而非「I.」;在荷兰的文字游戏中,⟨IJ⟩ 填充在一个空格里;荷兰的打字机上也有一个留给 ⟨IJ⟩ 的键位;甚至有些变种字母表干脆把 ⟨IJ⟩ 放在了 ⟨X⟩ 与 ⟨Z⟩ 之间,使之成为第二十五个荷兰文字母。很多著名字体包含大小写 ⟨IJ⟩/⟨ij⟩ 的「连字」,无一例外地以某些形式强调了这个字符的整体性。

字体 Linux Libertine 对这些字符的处理

不仅如此,在手写时小写 ⟨ij⟩ 之间的连笔牵丝使之看上去像一个带分音符的字母 y ——而这并不会造成混淆:因为荷兰文原本没有字母 y ,遑论带附标的 ⟨ÿ⟩。有趣的是字母 Y 的荷兰语名称音也是 [εi],不作硬区分就没法区别开。与手写字体不同,印刷字体中的小写 ⟨ij⟩ 连字一般会有意识地跟 ⟨ÿ⟩ 区别开。至于它究竟属于哪一种连字,则取决于我们的观点:若是把 ⟨IJ⟩ 视作两个字母,那这个字形便是个排印学连字;但当我们将其作为一个字母看待时,它就是个正字法连字了。Unicode 为这游走于双字、连字与字母之间的字符准备了两个码点 U+0132 U+0133,并称其为「连字」。或许,⟨IJ⟩ 的现状是它从多重字母迈向正字法连字与独立字母之间的一步,而我们又何尝不是在见证历史呢。
单独的字母并不是连字唯一的演化方向,长期使用的连字也有可能会成为符号。Ampersand (&)「与号」便是绝佳的证明。它的外观变化多端,但全都指向了这个符号的起源:拉丁文 et 的连字。在希腊文和亚美尼亚文中也存在与 ampersand 类似功能的字符,不过今天我们一般认为它们是连字或字母而非符号。Number sign (#)「井号」在今天一般用来表示数字,可它其实是拉丁文 libra pondo 的缩写「lb」的连字,在使用中逐渐简化为纵横交叉的形式。从井号的另一个名字 「pound sign」 中亦可看出它的字源。Interrobang (‽)「问叹号」则是两个标点的嵌合体。

字体 Constantia 和 Ginóra Sans 的与号、井号和问叹号

除此之外,一些货币的符号起源于连字,或是以连字的形式被造出来。一部分天文学符号——准确说来是天体符号——和许多标准炼金术符号同样以连字或类似连字的形式呈现。在其它领域也星星点点地分布着这样的符号。这些符号有相当一部分是直接以连字的形式创制的、而不是长时间沿用形成的变形,性质类似旧时家族姓氏首字母缩写构成的花押。不难看出,这种花押传统在今日得到了良好的继承。

Unicode 拥有十二个国际音标连字,其中有六个是排印学连字。这三对塞擦音之所以入了 Unicode,只是因为它们比别的塞擦音更常用一些而已。如今无论是国际音标还是 Unicode 都不建议使用这六个排印学连字。国际音标扩展则增添了三个新的正字法连字,也具有 Unicode 码位。 Unicode 在此之外还收录了很多不常见的拉丁字母连字,绝大多数是正字法连字;但在另一方面,诸如 ⟨ct⟩ 连字等等沿用已久的排印学连字却没有 Unicode 码位。而这是情有可原的:Unicode 是一个字符编码标准,不是字体排印标准。 Unicode 认为,排印学连字的字符以及显示行为应当交由字体文件在字形层和字体层完成,并不需要为它们单独编码。如果我们想要呈现一个特定字体中存在的排印学连字,只需在字符层输入所有构成它的字符序列,然后交给字体与排版引擎渲染就可以了。至于 Unicode 中已有的排印学连字,基本上是为兼容性着想或是与非 Unicode 编码体系往返转换所用,一般情况下用不到也不建议使用。因为正字法连字可以认为是单独的字母,所以它们能作为「字母」被编入 Unicode——而隔壁的排印学连字则不会再获得任何码点了。

字体 Mrs Eaves 中丰富的排印学连字

既然处理排印学连字是字体的工作,一款完善的西文字体就应该担起重任。如今在 OpenType 特性的加持下,现代字体可以为一些字符组合提供不同的字形,与连字相关的 OpenType 特性有 5 个:标准连字 liga、自由连字 dlig、历史连字 hlig、上下文替换连字 clig 以及需求连字 rlig。要正确显示使用了这些特性的文本,还需对应的文字渲染引擎支援,并且确保我们需要的特性保持开启。哈哈,从我们的日常生活中可以看到,连字的正确调用或许确实还有很长的路要走。

说了这么多拉丁字母,连字在拉丁字母之外也在以自己的方式生生不息。希腊字母在手抄本中存在相当数量的连字,有些还进入了诸如 Caslon 等著名拉丁印刷字体中。除了前面提到的 καί 连字,Unicode 中还有一个被称作「stigma」的 ⟨στ⟩ 连字,用作希腊数字 6 或者 600。在某种意义上,⟨ο⟩ 和 ⟨υ⟩ 的连字在 Unicode 也有一席之地,只不过被编入的是它的拉丁与西里尔后裔。

与希腊连字相比,进入 Unicode 的西里尔连字更多一些,而且基本上是正字法连字。这里需要注意,西里尔字母 Ю 的前身是 ⟨І⟩ 与 ⟨О⟩ 的连字,而字母 Ю 本身和拉丁字母 W 的境况相仿。另一个西里尔字母 Ы 同样保持着 ⟨Ь⟩+⟨І⟩ 连字的外观,尽管它其实是从 ⟨Ъ⟩+⟨І⟩ 连字演变来的。

字体 Segoe UI 中的一部分西里尔「连字」

在日耳曼人古老的卢恩字母中,我们时常会发现一种名为「Bind Rune」的连字。顺带一提,蓝牙的标识其实也是一个 Bind Rune,这个符号由卢恩字母 ⟨ᚼ⟩ 与 ⟨ᛒ⟩拼合而成,对应着丹麦国王「蓝牙王」Harald Blåtand 的缩写。亚美尼亚文在 Unicode 中拥有 6 个连字。直排的日文假名也曾有许多连字或合字形式,其中只有两个在今天取得了 Unicode 码点:平假名「ゟ」U+309F 和片假名「ヿ」U+30FF。在中日韩兼容CJK Compatibility区块有很多以片假名写就的计量单位小方块,它们只是这些单位的一种显示形式而已,并不是某种连字。

在阿拉伯文与婆罗米系文字中,字母通常具有不同的组字形态,涉及这些文本 的特质、复杂文种处理与其他 OpenType 特性,但这已经离题太远,在此恕不讨论。 至于那些由几个汉字融为一体的汉字连字——「合文」,我们还是另起炉灶吧。

连字不仅仅是手稿与活字的守望者。在信息高速公路上,连字进化出了新的机能:提升代码的可读性。一部分专为写代码而生的等宽字体具有这个功能。排印学连字提升代码可读性的措施大致有三种:

  • 最常用的是稍微改换字形、突出一些字符的特征,用来区别形近的字符组合,抑或使重复的符号更容易记数;
  • 其二是改写字符组合使之更直观明了,比如将叹号 ! 与等号 = 渲染为两倍字宽的不等号,或是将 HTML 的注释语法 <!-- --> 呈现为完整的一对等等;
  • 最后则是连字越俎代庖做了 kerning 的工作,为本不需要调整任何 kerning 的等宽字体优化一些字符间距。

字体 JetBrains Mono 的一部分代码连字

如此一来,代码块的可读性确实提升了,但实际上前两种连字反而降低了单个字符的易认性legibility。有些开发者不习惯这样的连字,设计师们一般也会推出一个没有连字的字体版本,为传统开发者「向后兼容」。

演化与流变、分离与统一,透过排印学连字与正字法连字共舞的双螺旋,我们得以一窥连字的演化历程。排印学连字兴于活字铅条之中,在二十世纪后期一度隐匿行踪,但随即借 OpenType 之力直上高级字体特性的青云;正字法连字源出手稿抄本,于时间的浪潮里合为一体,在字母表中安家落户、繁衍生息。连字虽不言语,但一呼一吸间,或深或浅,我们总能捕捉到羽毛笔和铸字机在历史隙隅的悠远回声。


排字工当然知道字母 i 的点点是不好吃的。

Notes


References


Author

万「字」皆可「连」 (影片文案)

https://vistudium.top/2023/02/16/e04_ligatures/

著士

Siphercase

作於

2023-02-17

協定