前言
在html/css中，我们已经习惯了其带来的便利，要展示一段文字，直接把内容写进一个节点（如<p>）就行，设置好css的字体名、大小、行高、颜色。最多用到某种不常见的字体，稍微麻烦点通过font-face引入一下即可。
<style>
p
 {

width
: 
200px
;

background
: 
#F00
;

font-family
: 
'PuHui'
;

font-size
: 
16px
;

  }

@font-face
 {

font-family
: 
'PuHui'
;

src
: 
url
(xxx.ttf);

  }

</style>
<p>
html的文字标签和css样式16px普惠体。
</p>

声明式的标签结构，和面向切面的css排版样式使得web前端开发极为便利。
困难
然而在canvas中，一切都要从头开始。
字体加载可以用js中FontFace()和document.fonts.add()方法做，字体使用可以用ctx.font，渲染文本可以用ctx.fillText()。虽然麻烦了点但还是可以办到的。
排版换行怎么办？
最简单的，使用ctx.measureText()测量单字符宽度，然后一个个字符从左到右依次累加，超过则说明需要换行。这也是最常见的最基础的一种办法，很多方案都采用它。
如：https://www.zhangxinxu.com/wordpress/2018/02/canvas-text-break-line-letter-spacing-vertical/
看上去很美好，实际则暗藏玄机。另：svg类似，只是测量方式不一样，使用innerHTML+getComputedStyle()。
国人不常见的比如阿拉伯文字母 م，在单独书写时很正常，但在单词上下文中，就有不同的变体，连续多个时不是简单的拼接，而是 ممم。
这段红色标明的阿拉伯文，在浏览器上阅读时可以很明显地看到3个字母连续时的变化，常见的chrome/firefox浏览器用的是HarfBuzz。https://harfbuzz.github.io/why-do-i-need-a-shaping-engine.html
即便是常见的英文单词和数字，也普遍存在这种情况。
比如基础字形Arial、tahoma、苹方、宋体，它们的数字1字母f，都有类似情况出现。
karas.render(

<canvaswidth="360"height="360">
<
spanstyle
=
{{
      fontSize: 32,

      fontFamily: 'Arial',

      background: '#F00',

    }}>
1111111111
</span>
</canvas>
,

'#test'
);


可以看到，连续的字符1发生了书写变体，整体宽度比单个字符宽度之和要小，这反应在单行inline节点的尺寸（背景色）上。如果不用文本整形修正，尺寸和换行等计算全部会受影响，从而产生误差。
使用HarfBuzz，可以清楚地看到测量结果确实如此。

https://harfbuzz.github.io/harfbuzzjs/


解决
既然单字符累加的方式有隐患，那么整体测量呢？
幸运的是，无论是canvas的ctx.measureText()，还是svg的getComputedStyle()，都可以将任意整段文字内容传入来测量，测量的结果浏览器底层已经包含了文本整形，因此它不会产生偏差！
ctx.measureText(
'1'
).width * 
3
; 
// 53.390625
ctx.measureText(
'111'
).width; 
// 48.640625
这样的话，如果是测量宽度绘制单行inline背景色等场景，直接使用整体的结果即可。
那么多行换行呢？
简单办法依旧是累加，不过不再是单字符宽度累加，而是从第1个字符开始不断增加内容整体测量，直到>容器边界。
let
 str = 
'111111'
;

let
 widthLimit = 
50
;


for
(
let
 i = 
1
, length = str.length; i <= length; i++) {

let
 s = str.slice(
0
, i);

if
(ctx.measureText(s).width > widthLimit) {

// 超过换行操作等
break
;

  }

}

这里有个性能隐患，因为ctx.measureText()方法是和浏览器c/c++层交互，传递的是字符串内容，但js字符串截取再传递的性能消耗还是有的，如果容器尺寸比较大，文字又特别多，整个循环消耗就容易产生耗时。
karas目前使用了一种预测剩余宽度的算法。在给定fontSize的情况下，中文单字符一般宽度就是fontSize，英文一般在[0.5,1)的样子。其它语言都类似，因此假定一下一个字符占fontSize * 0.8，预估出容器边界widthLimit情况下，平均能容下多少字符进行测量。根据测量结果的误差，重复增减假定个数即可。
它能大大减少循环的次数，比普适的2分法表现还要好许多。

https://github.com/karasjs/karas/blob/8e35727421a59f2d4ab16b003ceb7200ab55b262/src/node/Text.js#L56-L163
场景
文字排版完善之后，常见的图文混排卡片渲染场景、个性化分享页等就不在话下。

即便是中文常见的标点悬挂，现代浏览器正则支持兼容性的也很好了。

除此之外，还有个大热门超难场景：web在线文档。
关于canvas实现doc的优劣细节不再多说，网络有很多讨论。这里选取比较常见canvas实现的代表测试下：google doc和腾讯文档。


google doc不仅有基础的文本整形，还有双向文本BIDI支持，毕竟是偏国际化的，但是没有字间距，即css的letter-spacing。


腾讯文档也有基础的文本整形，但没有双向文本，主打国内。有字间距，可惜的是，在文本整形的情况下失效了，本来应该变形的连续阿拉伯字母，变成了独立分开的形状。
这也情有可原，因为ctx.fillText()并不支持letter-spacing的设置，想要达到这一效果，只能回退到单个字符渲染的方案。这种情况没法使用整形，于是就降级为测量/渲染“错误”了。
那么有没有解决办法呢？
前面提到了Harfbuzz，官方提供的demo页面，仔细看发现是wasm，它可以使用js对已知字体文件（如ttf）的整段文本进行整形测量。
在线文档这个场景下面，由于可用字体是有限且已知的，因此当有letter-spacing时，宽度测量可以依旧使用ctx.measureText()，然后再加上字符个数 * letter-spacing，这样就能得出真正的尺寸。
渲染的时候呢，先按照无letter-spacing渲染到离屏画布上作为一张位图，再通过Harfbuzz的整形信息切割单个字符，重新ctx.drawImage()到主画布即可。只是性能没有实际测试过，这也是wasm存在的意义。


以上即是对文本整形的详解探索，如有错误请指正。
文字排版渲染只是普通渲染场景的冰山一角，随着功能的增多完善，像行级块级、图文混排、white-space、line-clamp、标点挤压，难度将呈几何级上升，不过这些是题外话超纲了，有机会另行叙说。
关注「Alibaba F2E」微信公众号把握阿里巴巴前端新动向
继续阅读
阅读原文