主要是 text justify 相关和标点挤压相关。

我博客的 Markdown 渲染基于 unified，所以下面的一些优化是以 unified 插件（remark / remark-rehype / rehype 插件）的形式实现的。

text justify 相关

在每行的宽度略有差异时，使用两端对齐会让中文排版更加美观，这一般通过 text-align CSS 属性 的 justify 选项实现。但由于网页排版的不确定性，每行的宽度可能不是略有差异而是有很大差异，这时使用 text justify 就会造成过大的空隙，所以需要避免出现过短的行，或者在有必要时禁用 text justify。

lang="zh-CN" 对 text justify 的影响

这个并不是 trick，是基操，但挺重要的，还是写在这。

如果没有将 HTML 的 lang 属性 设为中文，在 Firefox 109（以及其他版本 / 其他浏览器，但不包括 Chrome 109）中就会按照英文的规则，将连续的汉字视作一个单词，而只在词与词之间增大间距，不改变汉字之间的间距，如下所示：

这是一个设置了 lang="en" 和固定宽度的段落，这是一个 loooooooooooooooong word。

其中，第一行没有两端对齐，而第三行只在逗号后面增加了间距。

如果设置了 lang="zh-CN" 则会在汉字间添加间距：

这是一个设置了 lang="zh-CN" 和固定宽度的段落，这是一个 loooooooooooooooong word。

当然，设置 HTML 的 lang 属性还有其他作用，不管怎么样总是得设一个的。

断开过长的行内代码

有时候会遇到一些 veryLoooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooongInlineCode，为了让它不断开，前面的一行就会非常短，justify 后间隙就非常大。当然，这样的问题不局限于行内代码，但正常的英文很少会遇到特别长的单词，代码则经常遇到，所以我选择对代码进行处理（主要是因为不需要分词套 <span>）。

思路很简单，就是把过长的 :not(pre) > code 通过 <wbr> 或者 word-break: break-all 断开，让它不可断开的部分没那么长。例如：<code>word<wbr>-<wbr>break<wbr>: <wbr>break<wbr>-<wbr>all</code>、<code>&lt;<wbr>code<wbr>&gt;<wbr>word<wbr>&lt;<wbr>wbr<wbr>&gt;-&lt;<wbr>wbr<wbr>&gt;<wbr>break<wbr>&lt;<wbr>wbr<wbr>&gt;: &lt;<wbr>wbr<wbr>&gt;<wbr>break<wbr>&lt;<wbr>wbr<wbr>&gt;-&lt;<wbr>wbr<wbr>&gt;<wbr>all<wbr>&lt;/<wbr>code<wbr>&gt;</code>……（禁止禁止套娃）。

具体实现：breakLongCode.ts

1. 如果按空格分开没有超过 10 个字符的部分，不进行处理；
2. 如果按正则表达式的 \b 分开没有超过 12 个字符的部分，则在 \b 处插入 <wbr>；
3. 如果按 \b 以及下划线分开没有超过 15 个字符的部分，则在相应位置插入 <wbr>；
4. 否则，没救了，直接 word-break: break-all。

当然这个粗糙的处理方式还是有一些问题，比如从上面的示例就可以看出来，期望结果可能是 <wbr> / <code> 不被断开，但实际上会在 < 后 / > 前断开。

UPD：链接也可以用同样的方法进行处理。

在小屏幕上对窄的元素禁用 text justify

有的时候容器宽度太小，即使是正常的普通文本也不适合进行 text justify。

我选择了一个非常简单粗暴的处理方法：认为窄的元素 = 小屏幕上嵌套了多级的元素。

.article-style {
  text-align: justify;
}
.article-style > * > * {
  text-align: initial;
}
@media (min-width: 40em) {
  .article-style > * > * {
    text-align: inherit;
  }
}

.article-style {
  text-align: justify;
}
.article-style > * > * {
  text-align: initial;
}
@media (min-width: 40em) {
  .article-style > * > * {
    text-align: inherit;
  }
}

（上面放的是编译出来的 CSS，源码是使用 UnoCSS 的 SCSS。）

一些细节：

• 使用 * 选择器，specificity 很低，便于 override。
• 只选择 > * > * 而非 * *，这样的话嵌套更深的元素依然从 parent 继承 text-align，就可以设置 CSS override 掉一整个子树。（之前我一度以为 katex 不自带行间公式居中，后来发现是被我的 CSS 改掉了 text-align。）
• 使用 inherit 而非 justify 进行撤销。

对包含过长行内公式的元素禁用 text justify

除了 行内代码，$\text{行内公式}$ 也是常见的过长的不可断元素。这里我采用了一个本文最 dirty 的处理方式：在客户端通过 JavaScript 检测宽度过大的行内公式。

具体实现：TextJustifyFix.vue

• 只修改 text-align: justify 的元素，如果已经设置为其他对齐方式（例如表格中的居中对齐），就不应修改。
• 使用了 document.fonts.ready 来等待字体全部加载好再检查宽度。

标点挤压

代码实现：mojikumi.ts、mojikumi.scss。

相邻标点的挤压

例如：「：“。”（。）」→「：“。”（。）」。当然本页其他地方也有一些例子。

具体规则 clreq 中说的比较模糊，可以参考 jlreq。

使用 CSS 去除标点的一半空白

CSS 实现标点挤压有两种方式：

• 使用 letter-spacing: -0.5em 去掉右侧空白，margin-left: -0.5em 去掉左侧空白。
• 使用 font-feature-settings: "halt" 将支持 halt 特性的字体变为半宽。

使用 letter-spacing 是有讲究的，比 margin-right 靠谱，因为字符真的会只占半宽，而不是占全宽但一半和下一个字符重叠，甚至造成 overflow，可能导致滚动条出现。但 letter-spacing 不能去掉左侧空白，就只能使用 margin-left 了。

通过 halt 特性变为半宽是更加靠谱的做法，但不是所有字体都支持这一特性，思源宋体是支持的，霞鹜文楷 不支持。并且，halt 只能变为半宽，不能变成其他宽度。

行首行尾标点的挤压

这里参考了 Han.css 的实现，就是把全宽的标点改成半宽标点和一个通过 ::before 或 ::end 添加的半宽的空格：

• 因为是 pseudo element，所以不影响文本内容（例如复制出来的文本）。
• 因为是空格，所以位于行首或行尾时就会发生空格塌陷。

英文标点的处理

我采用了一个比较简单的判断英文标点的方法：

• 空白一侧（左括号、左引号等是左侧，其他一般是右侧）是空格时是英文标点；
• 右单引号右侧是字母时是撇号。

英文标点一般调为半宽即可，但撇号半宽还是有些太宽了，应该（根据字体而定）调成大约三分之一宽，单引号也可以调窄一点，所以可以特判一下单引号，使用 letter-spacing 和 margin-left。

给霞鹜文楷添加 halt 特性

因为 添加 halt 特性的 issue 被拒了，我就自己改了一个 标点字体，顺便把引号改成了和思源宋体一致的全宽以方便一起处理（也可以理解为改引号宽度顺便添加 halt 特性，毕竟没有 halt 也可以用 letter-spacing 和 margin-left 凑合一下），具体可以看仓库里的 patch 文件。

关于 chws 特性

chws 特性 可以根据上下文自动挤压连续标点，一眼看上去似乎比 halt 更好用。

思源宋体不支持这一特性，只不过有 chws_tool 可以用来转换。

但是，chws 不支持行首行尾标点挤压，而如果要支持行首行尾挤压，就得把支持连续标点挤压的工作做一遍（因为要知道哪些标点已经被挤成了半宽哪些只在行首行尾挤成半宽），这样一来 chws 就没多大意义了。

Yet another mojikumi？

有一些现成的支持标点挤压的库，例如 heti 和 Han.css。但是我有一些需求：

• 要能 SSG （SSR），不能在客户端运行。最好是能在 remark / rehype 中进行处理。
• 最好是尽量使用 halt 而非 letter-spacing 和 margin-left。
• 要能添加一些自定义的规则，比如对单引号特殊处理。
• 我只需要标点挤压，不想要一个 CSS 全家桶，或者带有其他功能的 JS。

现有的库难以同时满足上面这些需求，所以我就自己写了。

本来想写一个通用的库，但通用的逻辑貌似没多少代码，不值得写成一个库。而我的整个 remark 插件又有点 opinionated，可能不太适合做成库（懒得做成库），想用的话可以在遵守 AGPL 3.0 的前提下直接复制（本文提到的其他代码也是一样，当然，如果是两三行的代码片段就不至于 AGPL 了，简单标一下出处就 OK）。

代码中的 Unicode（CJK）的字体

为什么马上要考抽代了你在这更新博客，我也很想知道（ 其实是在一个群里看到有人在聊博客的等宽字体，然后看了一眼自己的等宽字体，差点没想起来这个 trick 在干什么。

很多等宽字体是没有 CJK 字形的，在 Windows 的默认字体下，fallback 到 monospace 时中文会显示为宋体，而一般来说应当是黑体。所以可以为 Unicode 部分专门指定一个 fallback font，通过指定 unicode-range 来让 ASCII 字符依然 fallback 到 monospace。

@font-face {
  font-family: "Monospace Unicode Fallback";
  src: local("Noto Sans Mono CJK SC"),
       local("Source Han Mono SC"),
       local("Noto Sans CJK SC"),
       local("Source Han Sans SC"),
       local("Microsoft YaHei");
  unicode-range: U+1000-fffff;
}

:root {
  --default-mono-font: ui-monospace, DejaVu Sans Mono, Noto Sans Mono, SFMono-Regular, Menlo, Monaco, Consolas, "Monospace Unicode Fallback", monospace, var(--default-emoji-font);
}

@font-face {
  font-family: "Monospace Unicode Fallback";
  src: local("Noto Sans Mono CJK SC"),
       local("Source Han Mono SC"),
       local("Noto Sans CJK SC"),
       local("Source Han Sans SC"),
       local("Microsoft YaHei");
  unicode-range: U+1000-fffff;
}

:root {
  --default-mono-font: ui-monospace, DejaVu Sans Mono, Noto Sans Mono, SFMono-Regular, Menlo, Monaco, Consolas, "Monospace Unicode Fallback", monospace, var(--default-emoji-font);
}

为不同语言设置不同字体

其实我感觉我的做法有点丑（，还好有 UnoCSS 稍微强一点（

• 为每个样式（例如宋/楷）和每个语言分别用一个 CSS 变量记录当前字体。
• 改变样式时修改 font-family 为这个样式的字体，修改每个语言的字体为这个样式。
• 改变语言时修改 font-family 为这个语言的字体，修改每个样式的字体为这个语言。

语言通过 lang 属性标识。

详见 commit。

整一个另一种很新的中文字体网页嵌入方案（

这就是你 开坑 DDPP 不填的理由吗

背景

前不久看到 一种很新的中文字体网页嵌入方案，还想着没必要做这种优化，毕竟按 Google Fonts 进行子集化就可以做到每页 1MB 左右，按现代的网速不会有太大问题，用 devtools 开节流试了下看起来也还行。

然后我回家了，离开了校园网。虽然自定义域名的 Cloudflare Pages 还能访问，但速度暂且不论，丢包率就很有点恐怖，经常页面加载一半就卡住了。

再然后，Google Fonts 里 Noto Serif SC 的 unicode range 不含单引号（和撇号是同一个字符），导致 DDPP 序 里引用的那段话的撇号在我的手机上显示成了很宽的另一种字体，才让我发现这个问题。为了以后能及时发现这种问题，我就设置了不使用本地字体直接使用 web font 的 Stylus。

恐怖的丢包率，加上自己亲身体验 web font 加载，让我意识到了，在国内普通网络环境下，如果你的设备没有安装思源宋体，访问我的博客会是多么难受（

主体思路

“另一种”的主体思路和“一种”是一样的，就是把字体划分成常用字和非常用字。但是“一种”在这之后选择了使用动态规划 + 进化算法来对常用字进行进一步的拆分，“另一种”所做的优化则基于这样一个观察：虽然一个博客有一堆页面，但 80% 的人只会访问 20% 的页面（，一个字体是否常用，不仅要看出现在几个页面，还要看出现在哪些页面。

这时候，一直充当不蒜子平替（哪平价了啊）的 Plausible Analytics 就发挥作用了：近段时间的页面访问量可以用来估计每个页面被访问的概率，为常用字的划分提供可靠的数据支撑。

一旦估计出了每个页面的被访问概率，就可以对每个 glyph 分别计算出，如果在每一个使用了它的页面上都加载一遍，期望代价是多少，也就是使用了它的所有页面的被访问概率之和。如果这个数大于 1，就设为常用，否则设为不常用。

这个思路还是非常简单的，可以说只是“结合实际，采取启发式方法”，也称不上是一种新的方案（

具体实现

虽然思路简单，但实现起来还是有点复杂的，坑有点多。

获取页面使用的字体

如果整个页面都使用一种字体，直接看 HTML 里有哪些中文就差不多了，但我不仅非正文用的是黑体，引用块还是楷体，说不定在哪冒出来个等宽或者 $\LaTeX\text{公式}$，有时候还会加粗，更别提心情好的时候会像这段一样直接塞 <span class=""> 来修改样式。

一开始我通过 subfont 找到了 assetgraph/font-tracer，但这个 font-tracer 就两个 star，没有文档，AssetGraph 又是一个 12 年前的老项目，连 Definitely Typed 都没有，试了一下完全用不会。

想了想，最靠谱的还是直接交给浏览器来处理，所以就用 puppeteer 了。目前采用的算法是：遍历 <body>，跳过 <script> 和 <style> 子树，找到所有 Text 节点，再加上所有 <img> 的 alt 属性。找到节点后，可以用 getComputedStyle 获取 font-family 和 font-weight 等信息。

因为要处理很多页面，也要花一点时间，所以用了 puppeteer-cluster 来并行处理。（不知道为什么，在 vitest 和 iles 中运行时，不加参数会报错，而加了 --no-sandbox --no-zygote 之后并行的优化效果就差一些。）

代码：getPagesFontInfo.ts

字体匹配

完整的字体匹配是非常复杂的，我也没找到相关的库，就自己写了一个简陋的只匹配完整 font-family 和 font-weight 的算法。

其实一般 font-weight 也就 400 和 700，但我还是实现了一个 完整的 font-weight fallback。

代码：matchFonts.ts

常用字体划分

最关键的这一步实现起来是最简单的，因为是纯算法的，不涉及到可怕的 Web（

代码：getCommonGlyphs.ts

生成字体文件和 @font-face

我使用的是 subset-font 来生成字体子集文件。

这一步最大的困难，是正确地写出 @font-face。

一开始我是给常用字 (common) 和非常用字 (unique) 不同的 font-family，然后发现，在特殊情况下（幸好我的博客文章列表就触发了这个问题，不然真没想到），某个字的常规样式属于 common 而粗体属于 unique，由于 font-family 里 common 排在 unique 前面，就会匹配到常规样式，而加载不出粗体。

为了解决这个问题，common 和 unique 需要使用同一个 font-family。因为用过 Google Fonts 子集划分方案，我知道有不同 unicode-range 的 @font-face 是可以组合在一起的，难道我需要计算出精确的 unicode-range 写在 CSS 里？

为此，我粗略地读了半天（这两个词不冲突）CSS Fonts Module Level 4 W3C Working Draft，发现它说，unicode-range 可以比真实的 character map 大很多，若干 @font-face 的 unicode-range 也可以相交。但是，它没说两个 @font-face 能不能除了 src 啥都一样，而只说了：

Multiple @font-face rules with different unicode ranges for the same family and style descriptor values can be used to create composite fonts that mix the glyphs from different fonts for different scripts.

我也不敢依赖于实验结果，就没做实验，直接加上了粗略但是保证 common 和 unique 不相同的 unicode-range，具体来说就是 0 到最大的 code point。

这里从 0 开始也是有一定原因的：我在看 specification 的时候注意到一个奇怪的东西叫 first available font，虽然没太看懂具体是什么意思，但大致上感觉最好是让 unicode-range 包含空格，为了保险就从 0 开始了。

最后还有一个坑：如果 composite font 中两个 @font-face 的 unicode-range 相交，给交集内的字符匹配字体时，会按出现位置的逆序进行匹配。

这能有什么坑呢（，如果不动手试一试真的很难想到.. 按照整体的设计，访问一个页面时很有可能是 common 字体已经缓存好了，需要下载 unique 字体，如果 unique 的 @font-face 放在 common 的后面，就会优先匹配，从而阻塞住已经缓存的 common 字体，整个页面都要等 unique 下载好才切换字体，而不是先显示 common 再显示剩下的 unique。当然，反过来的话，unique 也会等 common，但这样一般来说是更好的。

还有一些细节优化：

• 生成 unique 字体文件时，文件名里有 hash 就够了，不要再添加和页面有关的信息，这样的话如果两个页面刚好 unique glyph 集合相同就可以共用一个字体文件。
• 如果一个页面一个 common glyph 都没用，就可以不添加 common font 的 @font-face。

代码：generateFontFiles.ts

将 CSS 写入 HTML 文件

虽然也有想过直接找到 </head> 文本替换，但为了靠谱还是用的 jsdom。

这部分的代码是最短的：injectCSS.ts

给项目起名

主体思路是把 glyph 分成两类分别对待，就很有 segregate 的感觉（

主要还是因为刚写了一个 segregated fit 印象比较深刻，所以就取了这么个名字。

在博客中使用

就是 从 iles 获取页面信息，从 Plausible Stats API 获取访问量，调用 Vite API 跑一个 preview server，然后调用 glyph-segregator。直接看代码吧。

访问概率的计算方式是，看每个页面近 90 天的访客数，加一后除以其中最高的加二（其实这个加一加二基本没啥用）。用最高页面访客数而非实际总访客数作分母，是想在算法的基础上更加偏向于划分到常用字一些，稍微优化一点访问页面较多的访客的体验，也可以少一次 API 查询。

更新常用字集合用的是 scheduled GitHub Actions，在 Docker 里跑是因为 Connection refused for local server in github actions workflow。

实际效果

整个 glyphSegregator 用时 40s 左右，glyph 数量和 common font file size (woff2) 如表所示：

首页只需加载两个 Regular 的 common font，每个页面需要加载的字体文件总大小缩减到了原来使用子集化的 1/4 左右，并且加载的字体文件数量从 10~30 个缩减到了 2~6 个。

作为对比，如果出现在两个页面就设为常用字，Noto Serif SC Regular 的 common 有 299KiB，出现在三个页面则是 227KiB。

后记：font subsetting 与 kerning

因为通过 Stylus 设置了不使用本地字体，我可以轻松地在本地字体和 web font 之间切换。然后我就偶然发现，切换时一些标题发生了字符的偏移。原因也很简单，就是相邻的两个字符本来有 kerning (字距调整)，但它们被划分到了不同的子集中，生成字体子集时就丢失了 kerning 信息。

我在 glyph-segregator 中 添加了 alwaysCommonGlyphs 选项（ASCII 字符总是设为 common，如果需要处理非 ASCII 字符的 kerning 也可以修改设置，但我的博客就假设只有 ASCII 字符会遇到这个问题）来解决这一问题。最好的解决方案是真的去看一下字体里有哪些 kerning 信息然后相应地处理，但是差不多得了（

后记的后记：还是改成了即使未被使用也添加进 common glyph set，否则如果新加一个 always common 的 glyph，为了让它 common，就会改变 common glyph set，导致 cache 失效。这里有一定的 trade-off，要在 cache 失效 / 多塞一些未被使用的 glyph / kerning 挂掉之间进行选择，我还是选择了多塞一些未被使用的 glyph，毕竟整个 ASCII 也没多大。最好是借助人类智慧来预测一下哪些 glyph 更有可能在未来被添加而放进 common glyph set 里，其他 glyph 就只有使用了才放，但是差不多得了（