设计稿上量出来字号一模一样，泰语用户看到的那行字就是比德语的小一圈

摘要：同一个字号在不同书写系统里不是同一个大小。保哥拿九种文字实测了一遍：拉丁系语言的麻烦全在横向，同一句话比英语长五成到一倍；非拉丁文字横向几乎不涨，麻烦全在纵向，印地语那一行的墨迹比英语高七成五。而所有响应式测试量的都是宽度。

设计稿上量出来字号一模一样，泰语用户看到的那行字为什么就是小一圈？

一家智能家居品牌的泰国站，反馈里反复出现同一个词

有个客户做智能家居，插座、灯带、传感器、网关这几条线。

泰国和印度是那一年新开的两个市场，页面是从英文站的设计稿本地化过来的。

上线三个月，泰国站的用户调研里反复出现一个反馈：字太小。

设计师第一反应是不可能，因为全站字号是同一套变量，泰语页面和英文页面读的是同一个值。

他把两个版本并排截图，量了像素，确实一模一样。

于是这条反馈被归进了主观感受那一类，处理办法是记录下来但不排期。这个判断在当时看不出毛病：字号是个数字，数字相同就是相同，用户说小只能是习惯问题。

印度站的反馈换了一个说法

同一份调研里，印度站的用户没说字小。

他们说的是挤，行和行之间粘在一起，读长段落容易串行。

设计师去看行高，也是同一套变量，一点五倍，跟英文站一致。

两个市场，同一套参数，两种不同的抱怨。

这时候他才意识到，如果参数完全相同而反馈不同，那出问题的一定不是参数本身。

后面这句话是整件事的转折点。字号和行高是你写进样式表的数字，而用户感知到的是这些数字作用在具体字形上之后的结果。这两者之间隔着一层，而那一层的换算比例，每一种书写系统都不一样。

把这句话说准确一点

字号这个值，规定的不是字有多高。

它规定的是字体设计者定义的那个方框有多大，字形画在这个方框里，具体画多满由字体决定。

拉丁字母的小写字母，通常只占这个方框的一半左右，剩下的空间留给大写字母、升部和降部。

泰文没有大小写，所有字母的主体都挤在一条窄带里，上下留出来的空间是给声调符号和元音符号用的。

天城文的字母主体比拉丁的小写字母大得多，可是它上面要挂一条顶线，下面还可能挂符号。

所以同一个字号，落到不同书写系统上，那个方框里被填满的比例、被填在什么位置、留给记号的空间够不够，全都不一样。这不是字体质量问题，是文字本身的结构决定的。

这件事为什么在英文站上从来不出现

整套排版参数的默认值，是照着拉丁字母调出来的。

浏览器默认十六像素，行高一点五倍左右，这两个数字对拉丁字母确实合适。

设计系统里那套字号阶梯，也是在拉丁字母上试出来的。

把这套参数搬到另一套文字上，等于把一套为特定字形结构优化过的常数，用在一个结构不同的对象上。

它未必立刻出错，但是它不再是被优化过的值，它只是一个碰巧还能用的值。

本站在别的话题上多次遇到同一个结构：一个常数在英语上被反复调优到最佳，然后被当成普适值搬走。可读性公式是这样，字符长度上限是这样，字号阶梯也是这样。它们的共同点是那个常数本身没有写错，只是它的适用范围从来没有被写下来过。

先说结论，免得后面越读越乱

实测下来这件事分成两半，而两半的方向正好相反。

拉丁系语言的麻烦全在横向：同一句话比英语长一半到一倍，撑的是宽度。

非拉丁文字的麻烦全在纵向：同一句话的宽度跟英语差不多，可是墨迹高出一大截，吃的是行高。

而团队做响应式测试时，量的全是宽度。

断点、折行、溢出、横向滚动，这四件事都是宽度的事。

纵向那一半没有对应的测试动作，因为在拉丁字母的世界里，文字的高度是个常量，没有人需要测它。下面把这两半分别拆开，数字都是保哥自己量出来的。

横向撑爆和纵向压扁，为什么是两笔方向相反的账？

先看横向这一半的实测数字

保哥拿同一句话在同一个字号下渲染，量它的实际墨迹宽度。

取的是电商站上最常见的那句加入购物车，各语言用当地站上的实际写法。

以英语的宽度为基准，德语长百分之六十三，波兰语和法语各长百分之五十八，芬兰语长百分之五十。

越南语长百分之七十四，俄语长百分之八十九。

最长的是希腊语，长百分之一百零四，也就是刚好翻倍。

这一列数字里没有任何意外，做过多语言站的人都知道译文会变长。真正值得注意的是它的分布：这七门语言全部是拉丁字母或者结构接近的字母文字，没有一个例外。膨胀是字母文字的共同属性，因为字母文字表达同一个意思需要更多个字符。

再看非拉丁那一半，数字完全不是一回事

同一句话，泰语比英语短百分之三。

印地语长百分之八，中文长百分之五。

三门语言的宽度都跟英语基本持平，横向那一整套麻烦在它们身上根本不成立。

如果只看这一列，会得出一个错误结论：这几门语言最好做，布局不用改。

换成高度那一列，结论立刻翻转。

同一句话在十六像素下的实际墨迹高度：英语十二像素，德语十二像素，泰语十二像素，中文十五像素，波兰语法语俄语越南语都是十六像素，印地语二十一像素。印地语比英语高出百分之七十五，而它的宽度只多了百分之八。

把这两列并排看，才看得出这是两个问题

德语：宽度加六成三，高度不变。

俄语：宽度加八成九，高度加三成三。

越南语：宽度加七成四，高度加三成三，两头都吃。

泰语：宽度减三，高度不变，但是主体带被压缩。

印地语：宽度加八，高度加七成五。

所以这不是一个膨胀问题的不同程度，是两个不同的问题：一个消耗水平方向的空间预算，一个消耗垂直方向的空间预算。它们的表现形式、检测方法、修复手段完全不同，而行业里只有前者有成熟的话术。

越南语是唯一两头都吃亏的那一档

越南语用的是拉丁字母，所以它继承了字母文字的横向膨胀，宽度加七成四。

同时它的声调记号叠在元音上方，有些字还叠两层，所以它又有非拉丁文字的纵向问题。

实测下来它的墨迹高度是十六像素，跟俄语波兰语同档，比英语德语高三分之一。

这解释了一个现象：越南语页面在窄屏上塌得特别快。

它既比英语宽，又比英语高，两个方向的余量同时被吃掉。

本站讲越南语声调记号那一篇算的是关键词覆盖那笔账，这里补上排版这笔。同一个记号，在词表里是要不要多收一行的问题，在版面上是要不要多留几个像素的问题，两笔账互不替代。

这两笔账各自会在什么地方爆出来

横向那一笔爆在有硬边界的地方：按钮、导航项、表格列头、筛选标签、卡片标题。

它的表现是文字被截断、按钮换行、横向滚动条冒出来。

纵向那一笔爆在有固定高度的地方：等高卡片、列表行、折叠区块、首屏内的信息量。

它的表现是记号被裁掉、行与行粘连、卡片文字溢出、首屏能看到的内容变少。

前一类肉眼一看就发现，后一类要盯着看才发现，而且很容易被当成设计风格。

这就是为什么泰国站的用户只能说出字太小这三个字，印度站的用户只能说出挤。他们描述的是同一个类别的问题，可这个类别在团队的词汇表里没有名字，于是两条反馈被分别归进了两个抽屉。

同一个字号下实测一遍，各书写系统的墨迹到底占多高？

这次实测是怎么做的

保哥用系统自带的字体，把同一批文本渲染成图，再逐像素统计。

拉丁、西里尔、希腊、希伯来、阿拉伯、越南语用同一款界面字体，泰文、天城文、中文各用系统给这几种文字准备的默认字体。

量三样东西：一个不带任何上下记号的基本字符有多高，一个真实的词连记号一共占多高，以及字体自己声明的那个行盒有多高。

灰度低于某个阈值的像素算墨迹，阈值统一。

这个口径不完美，它依赖具体字体，换一款字体数字会变。

但是它有一个好处：它量的是屏幕上真实出现的那些像素，而不是字体文件里声明的度量值。用户能不能读清楚，取决于前者不取决于后者，而绝大多数关于字号的讨论用的都是后者。

第一列：基本字符的高度，结果跟直觉相反

在十六像素下，拉丁字母的小写字母主体高八像素。

西里尔、希腊、泰文、越南语的基本字符也是八像素，跟拉丁完全一致。

希伯来字母九像素，阿拉伯字母十像素。

天城文的基本字符十二像素，比拉丁高一半。

汉字十四像素，比拉丁高七成五。

换句话说，同一个字号下，天城文和汉字的字形本来就比拉丁字母大。要让它们的基本字形缩到跟拉丁十六像素一样高，天城文只要十一像素，汉字只要九像素。这个结果直接推翻了那个最流行的解法：给小语种页面调大字号。对这两种文字来说，字根本就不小。

第二列：真实词的全高，这才是占地方的那个数

基本字符只是主体，真实的词还要带上记号和升降部。

十六像素下，英语一个真实词的墨迹高十六像素，德语十二像素，泰语十三像素。

波兰语、法语、俄语、越南语都是十六像素，中文十五像素。

印地语最高，一个短句量出来二十一像素。

把第一列和第二列并排看，泰文的情况就清楚了：它的基本字符只有八像素，跟拉丁一样，可它的全高是十三像素，多出来的五像素全给了上下两层记号。也就是说泰文的信息被压进了一条比拉丁窄的主体带，上下的空间还得分出去。

第三列：行盒是个常数，墨迹不是

字体会声明一个行盒高度，浏览器拿它做默认行高的基准。

十六像素下，那款界面字体的行盒是二十三像素，中文字体是二十二像素。

这个数字在同一款字体里对所有文字都一样，不区分书写系统。

可墨迹从十二像素到二十一像素不等，最大差九像素。

于是同一个行盒里，拉丁字母上下各留出五六像素的余量，印地语只剩下一两像素。

行盒这个常数是整件事的核心矛盾：排版系统假设一行文字的高度是可预测的，而这个假设只在单一书写系统内部成立。一旦一个网站要同时排版拉丁、泰文和天城文，这个假设就不再是安全的默认值，它变成了一个需要按语言重新设定的参数。

把三列合起来读，能读出三个不同的病

拉丁系语言：基本字符八像素，全高十六像素，行盒二十三像素，余量充足，纵向没病。

泰文：基本字符跟拉丁一样小，全高偏低，可主体带被记号挤压，病在细节看不清。

天城文：基本字符大，全高逼近行盒，病在行高不够。

汉字：基本字符最大，密度最高，病在小字号下笔画糊在一起。

四种病，四种解法，而它们在样式表里对应的可能是同一行代码。

这就是为什么按语言另设一档不能只调一个参数。给泰文调大字号，主体带确实变大，可它同时把本来就够用的宽度撑开了；给天城文调大字号，行高更不够用；给汉字调大字号，密度问题一点没解决。诊断错了变量，改动就只会把另一个指标弄坏。

那个默认的行高倍数，为什么在天城文上刚好不够用？

一点五倍这个数字是从哪来的

行高一点五倍是现在最常见的正文设定。

它有两个来源：一是长期的排版经验，二是无障碍规范里的一条要求。

规范那一条说的是，用户如果把段落行高调整到字号的一点五倍，内容不能因此丢失或者失去功能。

注意它的措辞，它规定的是页面必须能承受这个调整，而不是说一点五倍就是合适的行高。

很多人把它读成了推荐值。

这个误读在拉丁字母上没有代价，因为一点五倍对拉丁字母确实合适，误读之后得到的答案碰巧是对的。这类误读最难被发现，因为它从来不产生错误的结果，直到换一种文字。

算一遍余量就知道差在哪

十六像素配一点五倍行高，一行占二十四像素。

英语的墨迹是十二像素，剩下十二像素分给上下行间。

波兰语和俄语的墨迹是十六像素，剩下八像素。

印地语的墨迹是二十一像素，剩下三像素。

同一套参数，行间空隙从十二像素掉到三像素，只剩四分之一。

这三像素是什么概念：两行文字之间几乎没有视觉分隔，眼睛在换行时找不到落点，读长段落容易串行。这正是印度站用户反馈里那个挤字的来源，他们描述的不是字号，是行间距，而团队去查的是行高参数，参数当然是对的。

行高不够的表现不是重叠，是裁切

很多人以为行高不够会看到两行字叠在一起。

实际很少这样，因为浏览器会保证行盒不重叠。

真正发生的是记号被相邻元素或者容器的溢出规则裁掉。

泰文的上声调符号、天城文的上标元音、越南语的第二层记号，都在最上面那一两个像素上，窄屏上的阿拉伯语版面也有同一族问题。

一个设了固定高度并且隐藏溢出的卡片，裁掉的正好是这一层。

裁掉一个记号和裁掉半个字母的后果完全不同：半个字母还能认出来，一个丢了声调的越南语词是另一个词。本站讲换行与不可见字符那一篇里说过一次同类的事，那一篇是横向的，这一条是纵向的，两条加起来才是完整的溢出清单。

为什么调大字号救不了这个问题

直觉解法是把非拉丁语言的字号调大一档。

调大字号，行高按倍数跟着放大，余量的比例一点没变。

因为余量是按比例算的，而问题恰恰出在比例上。

十六像素配一点五倍剩三像素，二十像素配一点五倍剩三点七五像素，依然不够。

同时字号变大之后，横向宽度、卡片高度、首屏内容量全部被牵动。

正确的解法是调行高不是调字号：把行高倍数按书写系统另设一档，天城文和泰文给到一点七到一点八，阿拉伯语给到一点六五左右，其余保持一点五。这个改动只影响纵向，不牵动任何一个横向指标，代价小得多。

行高还有一个容易写坏的地方

行高的值要写成无单位的倍数，不要写成固定像素。

写成固定像素时，子元素继承的是那个像素值，而不是倍数关系。

一旦某个子元素的字号变了，它的行高不会跟着变，余量就塌了。

多语言站上这个坑更容易踩，因为你很可能给某种文字单独调了字号，却忘了它的行高是从上面继承下来的固定值。

这一条不是语言层的知识，是样式表的基础规则。

把它放进来是因为它和按语言分档这件事天然连在一起：只要你开始按语言给字号分档，继承链上任何一个固定行高都会变成一个定时炸弹，而在单语言站上它可以一直安静地待着。

区分两个词的那个记号，在十二像素下还剩几个像素？

先说这一测是怎么设计的

取一个基本字符，再取同一个基本字符加上区分词义的记号，两者分别渲染。

用后者的墨迹像素数减去前者的，差值就是那个记号本身贡献的墨迹。

这个数比记号的高度更有意义，因为人眼能不能分辨，取决于有多少像素落在那里，不只取决于它有多高。

测了四个字号：十二、十四、十六、二十像素。

八种文字各测一对。

这一测的目的不是给出绝对阈值，是给出一个相对排序：在同样的字号下，哪些语言的关键区别信息更容易被压没。

结果：最危险的不是看起来最复杂的那几种

十二像素下，希腊语的重音记号只贡献三个像素。

西里尔字母上那两个点也是三个像素，阿拉伯语的短元音记号三个像素。

拉丁字母的重音记号四个，希伯来语的元音点四个。

而泰文的声调符号有十个像素，天城文的元音记号有十个，越南语的叠加记号七个。

这个排序跟直觉正好相反：看上去最复杂、最陌生的那几种文字，它们的记号反而是完整的字形，占的像素多，缩小之后还认得出。真正危险的是那些只有一撇一点的小记号，它们在拉丁、希腊、西里尔、阿拉伯这几种最常见的文字上，而且它们承载的经常是词义级别的区别。

十二像素这个字号在页面上出现在哪

正文很少用十二像素，但是页面上有一大批文字用。

面包屑、规格参数表、角标、法律声明、商品卡片上的副标题、筛选器里的取值。

移动端还要再往下走一档，很多设计系统的最小字号就是十二像素。

这些位置有一个共同点：它们装的多半是精确信息，型号、规格、条件、限制。

而精确信息恰恰是最不能认错的那一类。

把这两件事叠起来：最需要精确的内容，用了最小的字号，而在几种主要文字上，区分词义的记号在这个字号下只剩三四个像素。这不是一个理论风险，它就是规格表看错的日常来源。

记号丢失和记号看不清是两回事

本站写过记号在数据管道上被丢掉的那一类问题，那是字符层的事，字符串里真的没有那个字符了。

这里说的是字符还在，渲染也正确，只是在这个尺寸下人眼分辨不出。

前者可以用脚本检出，后者任何脚本都检不出，因为数据完全正确。

前者影响检索匹配，后者只影响阅读理解。

两者的修复手段也没有交集：一个修管道，一个改样式。

把这两件事分开，是因为团队经常拿前者的检查结果去回答后者的问题。词表校验全绿，不等于用户在手机上能把这个词认出来。这两句话之间隔着字体、字号、对比度和屏幕。

低对比度会把这几个像素直接抹掉

三四个像素的记号，是靠这几个像素和背景的明暗差被看见的。

灰色小字这种流行做法，正好把这个差值压低。

对比度不足在无障碍检查里会被报出来，但是报出来的理由是整段文字的对比度。

没有一条规则会说，你这个语言的记号在这个字号加这个对比度下已经消失了。

因为这条规则需要同时知道字号、字体、对比度和这门语言的记号形态，四个变量。

所以这一层只能靠人在真实设备上看。判断办法很土但是有效：把页面在手机上打开，拿给一个母语者，让他念规格表里的型号和参数。念错或者迟疑的地方，就是记号被压没的地方。

笔画密度决定了哪一批文字先在小字号上糊掉？

密度这个指标怎么量

取一个真实的词，渲染出来，数它的墨迹像素有多少个。

再量它的外接框面积，两个数一除，得到墨迹占框的比例。

这个比例就是笔画密度。

比例越高，说明同样一块地方塞进去的笔画越多。

它跟好不好看无关，只跟能不能分辨有关。

之所以要单独量这一项，是因为前面两项都在讲尺寸，而尺寸够大不等于看得清。一个笔画极密的字即使尺寸很大，缩小之后相邻笔画照样会粘成一团，而尺寸小但笔画稀疏的字反而更耐缩。

实测排序，头尾差了一倍

十六像素下，汉字的密度是百分之四十四，最高。

希伯来语百分之四十四，越南语百分之四十二。

泰文百分之三十六，天城文百分之三十一。

拉丁百分之二十九，西里尔百分之二十九，希腊百分之二十七。

最低的是阿拉伯语，百分之二十一。

头尾差了一倍以上。阿拉伯语那条曲线连绵起伏、留白很多，所以它在密度上最占便宜；汉字和越南语在同样一块面积里塞进去的墨最多，它们最先糊。越南语上榜的原因跟汉字不同，它是拉丁字母加上叠加记号，记号把本来空着的上方填满了。

字号缩小时密度反而上升，这是关键的一步

把字号从十六像素降到十四像素，密度不但没降，还涨了。

汉字从百分之四十四涨到百分之五十二，希伯来语从四十四涨到四十七。

原因很朴素：笔画再细也不能细于一个像素。

字号缩小时，字形的整体尺寸按比例缩，可最细的那些笔画缩不下去，只能保持一个像素。

于是笔画占的比例被动上升，留白被吃掉。

这条机制解释了为什么高密度文字在小字号上的劣化不是线性的。它不是慢慢变模糊，而是过了某个尺寸之后突然糊成一团，因为在那个尺寸上相邻笔画之间的留白已经不足一个像素，两笔直接连上了。

在高密度文字上加粗是反效果

字太小看不清，第二个直觉解法是加粗。

加粗在拉丁字母上通常有效，因为它留白多，加粗之后对比更强。

在汉字、越南语、希伯来语这几种密度本来就高的文字上，加粗把仅剩的留白也填掉了。

结果是笔画更容易连成一片，反而更难认。

这一条在小字号上尤其明显，因为小字号本来就已经在密度上限附近。

所以按语言分档时，字重也要分档，而且方向跟拉丁相反：高密度文字的小字号位置应该用常规字重甚至更细的一档，靠对比度而不是靠笔画粗细来提升可读性。这个做法跟设计直觉是拧着的，需要在规范里写清楚理由，否则下一个设计师会改回去。

字体回退会把密度问题放大一档

网页字体没加载出来时，浏览器用系统字体顶上。

拉丁字母的回退字体和原字体在观感上通常差别不大。

非拉丁文字的回退结果差别可能非常大，因为设备上可用的那套字体未必是为屏幕优化过的。

本站讲非拉丁字形集与首屏成本那一篇算过体积这笔账，这里是它的下游：回退不仅意味着换了个样子，还意味着换了一套度量。

换度量之后，你调好的字号和行高全部失准。

最常见的表现是字突然变小或者变大一圈，然后在字体加载完成时再跳一次。这一跳既是观感问题也是布局稳定性问题，而它在非拉丁文字上的幅度比拉丁大得多。

用户把字体放大之后，最先塌的是哪一块？

规范里那条放大要求说的是什么

无障碍规范要求，文字放大到两倍时，内容和功能不能丢失。

这是AA级要求，跟前面那条行高要求同级。

它假定的场景是用户视力有限，需要更大的字。

验收方式很简单，把浏览器缩放到两倍，看页面还能不能正常用。

多数团队测过这一条，测的是英文站。

而这一条的通过难度在不同语言上完全不同，因为它的实际约束是：放大之后原有的布局余量还够不够用。而余量在各语言上本来就不一样，前面两节已经把这件事量出来了。

拉丁系语言放大后先爆横向

德语和俄语在原始字号下就已经比英语宽五成到九成。

再放大一倍，横向空间的缺口按比例扩大。

先出问题的是那些有硬边界的元素：并排的按钮、固定列宽的表格、导航项。

它们在英文站上刚好放得下，在德语站上勉强放得下，放大之后就放不下了。

典型表现是按钮文字换行、表格出现横向滚动、导航项挤成两行。

本站讲德语复合词那一篇讲过词长本身的问题，这里补的是它和放大要求叠加之后的效果：两个各自可控的因素乘在一起，就变成了不可控。做多语言站时，任何一条余量都要按最长的那门语言而不是按英语来留。

非拉丁站放大之后爆的是另一处

泰语和印地语的横向余量本来就够，放大之后横向依然够。

先出问题的是垂直方向：固定高度的卡片装不下，折叠区块的收起状态露出半行，首屏里的内容大幅减少。

还有一处更隐蔽：行高如果写成了固定像素，放大字号时行高不跟着变，行间距被压成负余量。

这时候记号就真的被切掉了。

所以同一条AA要求，在两类语言上要用两套测试脚本去验。

横向那一套业内已经有成熟做法，缩放到两倍看有没有横向滚动条就行。纵向那一套没有现成做法，能用的判据是：放大之后，带有固定高度的容器里，文字的顶部和底部有没有被裁掉。这个判断只能靠截图比对，或者在真实设备上翻一遍。

系统级放大比浏览器缩放更常见

做验收时大家习惯用浏览器缩放，那是最方便的方式。

真实用户更多用的是操作系统或者手机系统里的字体大小设置。

这两种放大的行为不完全一样，系统级设置改的是根字号，浏览器缩放改的是整体比例。

改根字号时，用像素写死的那些尺寸不会跟着变，只有用相对单位写的才会变。

于是页面会进入一个混合状态：文字变大了，容器没变。

这个混合状态才是真实用户遇到的那一个，也是最容易露出裁切问题的那一个。所以验收清单上应该写系统级字体放大，而不是浏览器缩放，两者测出来的问题不是同一批。

这一条该怎么测才省事

挑三个页面：一个信息密度最高的列表页，一个规格表最长的详情页，一个表单页。

每个页面各测两种放大方式，两倍缩放和系统字体调到最大档。

每种方式各截一张图，跟原始状态并排放。

看三件事：有没有横向滚动、有没有文字被容器裁掉、有没有两行粘在一起。

三件事各对应前面拆出来的一个病因。

这一套跑完不超过半小时，产出是六张对比图。它比任何一份自动化报告都更能说服人，因为裁掉的记号在截图上是看得见的，而报告里的分数看不见。

按语言另设一档字号，样式该怎么写才不失控？

用语言选择器，不要给每种语言复制一套样式

样式表里有一个按语言匹配的选择器，直接读页面上声明的那个语言值。

它的用法是给特定语言的元素追加几条属性，而不是重写整套样式。

这样做的前提是页面上的语言必须声明正确，声明错了样式就落在错的语言上。

这一点跟把同一个声明喂给发音引擎那一篇是同一个前提，那一篇讲的是页面语言声明错了之后整页会被怎么念出来。

同一个属性，一处喂给样式，一处喂给辅助技术，两处都靠它。

这也是为什么本站把语言声明列在多语言站必须最先做对的那几件事里：它不是一个孤立的标记，它是好几条链路共同的输入，而其中至少两条链路没有任何兜底。

先动行高，再考虑动字号

按前面的诊断，多数纵向问题的正确解法是行高不是字号。

给天城文和泰文的正文行高提到一点七五左右，阿拉伯语提到一点六五。

字号保持不变，横向指标一个都不受影响。

只有在小字号位置上才需要动字号，比如把非拉丁文字的最小字号从十二像素提到十三或十四。

这一档改动影响的是那些精确信息区域，收益最直接。

顺序很重要：先调行高看反馈，不够再动最小字号，最后才考虑动正文字号。反过来做的话，第一步就会牵动全站布局，改动大、风险高，而且往往解决不了真正的病因。

字体回退的度量差异用哪个属性兜

样式表里有一个属性专门处理这件事，它按小写字母主体高度来校准字号。

它的作用是：不管最终用上的是哪一款字体，让主体高度保持一致。

这样字体回退时视觉大小不会突然跳一档。

它对拉丁字母最有效，对没有小写字母概念的文字要用它的扩展写法。

浏览器支持这几年才补齐，用之前要确认目标市场的浏览器分布。

这个属性存在的理由本身就说明了问题：字号这个值不足以决定视觉大小，所以规范里补了一个专门校准视觉大小的属性。而这个不足，正是本篇从头到尾在量的那件事。

一份可以直接照抄的分档

拉丁与西里尔与希腊：正文十六像素，行高一点五，最小十二像素。

阿拉伯与希伯来：正文十六像素，行高一点六五，最小十三像素。

泰文与东南亚诸文字：正文十六像素，行高一点七五，最小十四像素。

天城文与印度诸文字：正文十六到十七像素，行高一点七五，最小十四像素。

中日韩：正文十六像素，行高一点七，最小十二像素，小字号位置避免加粗。

这份分档是从前面那几列实测推出来的，不是从哪本规范抄的，所以它需要按你自己站上的字体重新验一遍。验的办法就是本篇用的那套：渲染、量墨迹、算余量。换一款字体，数字会变，方法不变。

什么时候该换字体，而不是继续调参数

参数能救的是尺寸和间距，救不了字形本身。

如果一款字体在目标文字上的记号做得过小，或者缺少必要的定位规则，调参数没用。

判据是：把字号调到很大时，记号是否清晰、位置是否正确。

调大之后依然别扭，说明是字体问题，要换。

各文字的开源字体家族现在覆盖得相当全，换字体的成本主要在体积和加载策略上。

这条边界要划清楚，因为团队很容易在参数上反复调半个月，而问题从第一天起就在字体文件里。先花十分钟做一次大字号目检，能省下这半个月。

这件事最后会在搜索那一侧以什么形式结算？

首屏能装下多少内容，被这两笔账直接改写

同一块屏幕，德语站上装的字比英语站少四成，因为每个词更宽。

印地语站上装的行数更少，因为每一行更高。

首屏里能不能出现那段回答用户问题的文字，就是被这两个数决定的。

页面结构完全一样，主体内容的起始位置却不一样。

这一层不体现在任何一个技术指标上，它只体现在用户要不要多滑一屏。

做多语言站时，首屏的信息优先级应该按语言重排而不是共用一套。英语站上放得下的标题加副标题加三行摘要，在德语站上可能只放得下标题加一行，那就该砍掉副标题而不是让摘要沉到折叠线以下。

截断位置在不同语言上不是同一处

结果页上的标题和描述按宽度截断。

同样的字符数，各语言占的宽度差一倍，被截掉的位置自然不同。

本站讲芬兰语和泰语标题截断那两篇分别算过这笔账，那是检索展示侧的。

页面内部还有一套自己的截断，卡片标题、列表项、面包屑，它们按容器宽度截。

两套截断的边界不一样，同一个词可能在一处完整在另一处被切。

这里只提一句边界：本篇处理的是渲染尺寸，截断策略本身是另一层的事。两者的关系是，渲染尺寸决定了截断在第几个字符发生，而截断规则决定了发生之后怎么处理。

布局稳定性会被字体回退拖累

字体加载完成前后，如果两套字体的度量差别大，文字块的高度会变。

高度一变，下面的内容整体位移，这就是累积布局偏移。

拉丁字母上这个差值通常很小，非拉丁文字上可能很大。

所以同一套字体加载策略，在英文站上偏移可以忽略，在泰语或印地语站上可能踩红线。

能兜住的手段是把回退字体的度量对齐，以及前面说的那个按主体高度校准的属性。

这是本篇里唯一一个直接落在公开性能指标上的科目。其余那些，用户能感觉到，仪表盘上看不到。

可读性评分那把尺子在这里同样不作数

内容团队常用可读性分数来判断一段文字好不好读。

那套公式量的是句子长度和词长，跟渲染尺寸没有任何关系。

一段分数很好的印地语文字，在行高不够的容器里照样难读。

本站算过那把尺子的刻度是拿英语标定的，这里再加一条：它连排版这一维都不测。

可读性至少有两层，一层在文字里，一层在屏幕上。

两层要用两套方法验，而且屏幕这一层没有分数可用，只能靠实测和目检。这也是为什么本篇给的是一套量法而不是一个阈值。

真正的结算科目是体验不是排名因子

把这件事包装成排名因子是不诚实的。

字号和行高不是排名信号，改对了排名不会动。

它结算在三处：移动端的实际可用性、转化率、以及需要合规资质的那些市场里的采购门槛。

第三处正在变重，因为无障碍要求在越来越多的市场上从建议变成了法定。

做小语种市场的团队应该按这三处排优先级，而不是等一个排名解释。

本站在其它话题上反复说过同一句话：不是所有该做的事都需要一个排名理由。有些事的收益在漏斗更下游的地方结算，而那里的数字往往更大。

一份按书写系统分档的排版清单，以及哪些交出去

上线前的四项目检

第一项：拿本地语言的真实内容替换掉设计稿里的占位文字，看有没有溢出或者裁切。

第二项：把系统字体大小调到最大档，翻三个关键页面。

第三项：把最小字号那一档的文字放大到很大，检查记号形态和位置对不对。

第四项：在真机上让母语者念一遍规格表。

四项都不需要工具，加起来一小时以内。

四项分别对应前面拆出来的四个病因：横向余量、纵向余量、记号可辨识度、字体质量。做完这四项，剩下的问题基本都是设计偏好而不是可用性缺陷。

设计交付物里要多两列

设计规范里的字号阶梯，通常只有一列数值。

多语言站要多两列：这一档在非拉丁文字上的行高倍数，以及这一档的最小字号是否需要上调。

这两列不写下来，实现那一侧只能凭感觉，而感觉是照着拉丁字母长出来的。

交付物里最好附一张各语言的真实文本样张，而不是只给参数。

样张要用最长的那句和记号最密的那句。

本站在讲图片与替代文本那一篇里提过类似的做法：给规则不如给样本，因为规则会被理解成别的意思，样本不会。

内容团队要知道的一件事

内容团队通常不参与排版，但是有一件事只有他们能控制。

同一个意思在目标语言里往往有长短两种说法。

在按钮、导航、卡片标题这些硬边界位置上，选短的那个能省下大量返工。

这不是要求他们写得干瘪，是要求他们知道哪些位置有硬边界。

把有硬边界的字段列成一张表交给他们就够了。

这条在德语和俄语市场上收益最大，因为那两门语言的膨胀率最高，而它们恰好又都有丰富的同义表达可选。

哪些不归语言层，一句话交出去

字体文件的体积、子集化、加载顺序与闪烁策略，归性能那一层。

响应式断点、栅格系统、组件库的设计，归前端工程。

对比度、焦点样式、键盘操作，归通用无障碍访问工程。

低端设备和弱网下的整体表现，归移动端性能。

页面语言声明写在哪几处、写错了会怎样，归本篇的孪生篇。

本篇只处理一件事：同一套排版参数作用在不同书写系统上，得到的结果不一样，以及这个差异该怎么量、怎么补。

从哪一步开始最划算

如果只做一件事，做行高分档。

它改动最小，风险最低，收益最直接，而且不牵动任何横向指标。

如果能做两件，第二件做最小字号上调。

第三件才是正文字号，因为它会牵动全站布局。

第四件是字体选型，那是一个需要排期的项目。

这个顺序是按改动成本除以收益排出来的。多数团队的直觉顺序正好倒过来，先讨论换字体，再讨论调字号，最后才想到行高，于是最便宜的那件事排在了最后。

常见问题解答

我们直接给小语种页面把字号调大一档，是不是就解决了？

多半没解决对的那个问题。实测下来，天城文和汉字的基本字形在同一个字号下本来就比拉丁字母大一半以上，字并不小。真正不够的是行高和记号的可辨识度，调大字号会让行高更紧，同时把横向布局撑开。正确的第一步是行高分档，字号往后放。

这些数字换一款字体还成立吗？

绝对值会变，相对关系基本稳定。因为它们来自书写系统的结构差异：有没有大小写、记号叠几层、笔画密不密。这些属性不随字体变。所以照抄数字有风险，照抄方法没有，用同一套量法在你自己的字体上跑一遍就行，成本是半小时。

行高提到一点七五，页面会不会显得太松？

在拉丁字母上会，在泰文和天城文上不会。松不松是相对于墨迹高度的感受，同一个倍数在墨迹高的文字上换算出来的实际行间距更小。所以正确的做法不是统一一个观感最好的倍数，而是让各语言的实际行间距落在接近的区间里，倍数自然就不同。

为什么最危险的是希腊语和阿拉伯语的记号，不是泰文？

因为泰文和天城文的记号是完整的字形，本身占的墨迹多，实测在十二像素下还有十个像素。而希腊语的重音、西里尔的两点、阿拉伯语的短元音只有三到四个像素。像素越少越容易被小字号、低对比度和低分辨率屏幕一起抹掉，而它们承载的经常是词义级别的区别。

横向膨胀这件事，能不能靠自动缩小字号来兜？

能兜住不溢出，兜不住可读性。自动缩小通常发生在按钮和卡片标题这些位置，缩完之后那几处正好落进最小字号的危险区，而它们装的又是行动指令。更稳的做法是在内容侧选短的表达，在设计侧按最长的那门语言留余量，把自动缩小当成最后一道保险而不是常规手段。

我们只做欧洲市场，是不是就不用管纵向这一半？

欧洲市场里希腊语的横向膨胀最高，达到一倍，纵向问题确实弱。但只要站上有阿拉伯语或者希伯来语版本，纵向那一半立刻成立，这两门语言在欧洲市场的用户规模并不小。判断依据不是市场在哪，是你的站上有没有非拉丁书写系统的版本。

这件事该由设计还是前端负责？

诊断归语言层，执行分两处。行高与字号分档写在设计规范里，由设计出参数；语言选择器与字体回退的实现归前端。最容易掉在缝里的是那张按语言的参数表，因为它既不像设计资产也不像代码。建议把它和语言声明清单放在同一份文档里，两者本来就共用同一个输入。

权威参考资料