在终端或网页项目中，有时候验收 UI 时会发现文字的行间距会比设定的更大，和开发多次核对后得知，这是因为文字控件本身带有内padding，再加上设定的行距，视觉效果相当于是 padding 和 margin 叠加了。
而padding到底是多少呢？代码里是看不到的，sketch也看不到具体数值，不过可以通过字号和文字实际占用高度（即拖黑区域）来比较，通过控制字体包和字号两个变量。
前三个字体统一30px字号，行高分别为 1.4倍、1倍、1.5倍，而将最后一个字体包的字号改为20，行高又变成了1.45倍，说明不仅是不同字体行高不同，就连相同字体的不同字号，行高也并不是一个固定的倍数。
不同字体包、不同字号的行高对比
注：思源黑体在 Adobe 体系里称为思源字体 Source Han Sans，在 Google 体系里被纳为 Noto 字体体系一部分，字体包叫做 Noto Sans CJK SC ，两个版本字形和基线完全一致，区别在于行高和字重设定，这就导致在屏显文字的应用中，两个版本几乎要当作两种字体来处理。
值得一提的是，这个问题很早就被其他同事注意到（再往前一般是被当作玄学问题，只从操作层面解决，没有找到根本原因），当时经手的同事就猜测和字体包有关，只是还缺少更多细节。不过实践上已经可以解决问题：
-
非系统自带的第三方应用，除非自己打进一套字体，不然并不能控制不同终端的系统字体，所以设计稿推荐使用带一定行高的字体（除了source开头的思源黑体，其他的都可以），并允许小范围的系统性误差。移动端为iOS和安卓系统分别制作了两套字体规范，因为苹方和思源黑体的行高有差异，分别两套可以精细化控制排版。
移动端字体规范局部（iOS和安卓各一套）
-
和固件配套的系统应用，我们正好可以控制固件中打入的系统字体。但固件自带的黑体不一定全是 noto开头的，有些可能因为历史原因，打入了source开头的，所以调试和出货之前要统一确认是否打入了 noto 开头的字体。（下图为安卓原生固件中的字体，中文是NotoSansCJK-regular.ttc, ttc格式包含了多种字重，调用ttc字重的方法略）
找固件开发大哥挖掘的信息
-
source开头的黑体不建议用作终端应用的字体，因为它不带内padding，行高=1倍，如果不特别设定行间距，就会显得很密集，即使软件针对source字体做了排版优化，一跨平台又会出现更大偏差。
-
做UI稿一定不能用PS，因为PS在识别文字间距时，会以实际像素覆盖的区域为边界，相当于所有文字都变成padding=0，行高=1倍。
-
部分浏览器在渲染文字时会再次增加行高，需注意验收界面实际效果。
那这个问题还有什么没弄清楚的细节呢？留意上图中第三个思源黑体，在接近字底部的地方有一条蓝色线：
hover线
这是鼠标悬浮时被软件标记的线，重新打一段中英混排的文本，就知道这条线原来就是英文的基线：
中英混排的hover线
众所周知，英文字母的排列遵循三条参考线：基线、小写线、大写线，其中小写线也叫x线，大写线也叫升部线，有升部就有降部，比如小写字母 j ，下面超出基线的部分就叫降部了（当然要细分并不止这3条线）。英文的视觉重心在基线到x线之间的区域，大写字母横跨基线和升部之间的区域，所以整体重心会在x区域偏上一点。
中文的视觉重心逻辑不一样，中文的重心是中宫，中宫大约是文字中心1/3的区域。古文是竖排的，竖排时字的高矮没有要求，而宽窄变化，只要中宫对齐，外围收一点放一点也是可以的。现代汉语为了与其他语种（文化）衔接，改为了横排。如果依旧遵循中宫对齐，文字本身的高矮变化都会造成视线的起伏，增加阅读障碍。所以古早时期，中文在改横排时，就对一部分过于简单的文字进行了结构微调，比如把“心”字纵向拉高，达到纵向上量感匀称。
多语言混排时，如果直接让中文的中宫和英文的x区域等高并对齐，视觉上更加显得英文量感偏小、重心偏上了。
在中文中标出英文的x线
那文字混排时究竟应该遵循什么规则？特别是在多语种全球化、标准化过程中，屏显字体在设计时有没有什么公理呢？
先sketch打三段文本，用思源黑体 noto 版本打一段中文和英文，再用 roboto 同等字号打一段（yhx三个字母表示升部降部）。为了准确显示行高，因此三段文本是各自独立的文字控件。之前混排打字时得知，sketch会显示所有文字的基线，并且共享同一条基线，所以这里也让三个文字控件基线对齐。
参考线图解
字号 28， 用彩色块沿基线画出 28 的高度；发现色块高度全部比文字的本体都高，也就是文字的笔画不会超出字号所占的像素高度；灰色块是文字控件占用的高度，即“行高”，也是选中拖黑的高度。灰色块的高度全部大于彩色块的高度。
再把能标的参考线都标出来，共享的基线；英文的x线、升部线、降部线。刚刚说不止这几条，有些字母上端会超出升部线（案例里刚好没有），所以升部线以上还有上升线，降部线以下还有下降线，上升线和下降线在哪里，会不会刚好就是灰色区域的边界？
另外注意到，中文笔画中的撇、揦、竖、勾均会稍稍超出基线，而横却刚好贴着基线。也就是说中文字最底端的横画被标记为基线，用来替代中宫与英文对齐。横排文字中的基线可以作为视线引导，它是文字的内骨骼。中文撇、揦、竖、勾这些外延性的笔画会比基线更低，正好对应了英文中的降部。
为了进一步探索行高和参考线的关联，我发现了另一个厉害的工具 【 字体熔炉】——Font Forge
作为一个设计字体的工具，可以从微观角度展示字体文件的内部结构。
下图左边是用 Font Forge 画出来的字母 y，界面中也有显示 acender 上升线，descender 下降线。定义基线的高度为0。绘制文字的画布区域为 1000 unit。
那升部和降部呢？此刻他们分别等于上升线和下降线的值，所以上升线和下降线之间的距离刚好等于画布区域，也就是1000。此刻设计出来的英文字体就是两头贴边的。
右边为打开的属性， cap-height即大写线（升部线）。
字体包含的属性
下图为知乎用户李银城 制作的字体，网页上显示可见，不论多大的字体 ，上下都贴边，也就是没有padding。这里是用的英文测试，如果换成中文，根据在 sketch 上的试验，可以推测中文不会完全贴边（贴升部线和降部线），思源黑体source版本确实笔画也没有贴边，但彩色区域必定是等于灰色区域的（即行高=字号等额像素高度）。
使用自创的字体来测试行高
那市面上正规的字体打开是怎样的呢？
正规字体包的属性
字体设计界面和参考线
1415/1000 ，刚好等于1.4倍的行高。这也就解释了之前的现象，字体自带 1.2-1.4的行高，这与终端设定的排版格式无关，只与字族本身的属性有关。
那前端还可以控制吗？也可以，甚至可以设定比字体本身的更小的行高，所以有时候同一个网站在不同浏览器中显示的行高有区别。
参考：
字号与行高
前端基础系列之字体初探
网友评论