前端 - 一种字体为何可以同时匹配serif和sans-serif?

Question

AlibabaPuHuiTi-3-55-RegularL3.otf是sans-serif体，证明如下：

fc-match -s sans-serif:lang=zh | grep Alibaba
AlibabaPuHuiTi-3-55-RegularL3.otf: "Alibaba PuHuiTi 3.0" "55 Regular L3"

AlibabaPuHuiTi-3-55-RegularL3.otf也是serif体，证明如下：

fc-match -s serif:lang=zh | grep Alibaba
AlibabaPuHuiTi-3-55-Regular.otf: "Alibaba PuHuiTi 3.0" "55 Regular"
AlibabaPuHuiTi-3-55-RegularL3.otf: "Alibaba PuHuiTi 3.0" "55 Regular L3"

我就头大了，一个字体----AlibabaPuHuiTi-3-55-RegularL3.otf，可以同时具有serif和sans-serif，这两个不相容的性质吗？

Answer 1

没问题啊，只是你“认为”它们是不相容的，可在计算机看来他们都是字体，为什么只能用你不能用我？

而且字体本身并没有衬线、非衬线属性，这些是人为为了排版需求加的分组而已。

如果你学过前端，应该记得声明字体的最佳实践是英文字体在前而中文字体在后，想想看为什么？就明白计算机选择字体的逻辑了。

通常来说声明字体都是“分组”，而不是使用某一种具象化的字体，因为假如没有这种字体难道还不允许用户替代别的字体了？

比如声明中文字体、英文字体等等。中文字体本身也提供英文，难道中文字体不能渲染英文吗？这样你还认为他们是“不相容”的吗？

以你的场景为例，你想要使用“衬线字体”，或“非衬线字体”，这是一种分类而已，好比是你说“我要使用中文字体”，“我要使用英文字体”一样，并没有具体的某个字体名叫sans-serif或serif，对吧？那么他们在计算器看来就相当于某个分类字体，意味着叫sans-serif有一组候选字体，计算机从中挑选任意一个字体拿来用，这样理解没问题吧？再者说，难道衬线字体不能渲染非衬线字体吗？

那么所有的字体都可能是这个分组下的字体，都可以进入候选名单，因此你要做的就是控制优先级，符合分组条件的字体靠前，不符合条件的靠后，仅此而已。

fc-match -s是按照优先级列出匹配的字体，你只需要管你期望的字体是不是靠前就行了。比如你期望英文字体靠前，中文字体紧随其后，这样对于英文和中文都有不错的渲染效果。你要支持emoji,可能期望emoji字体更靠前，仅此而已。

EDIT: 即使你期望使用某个具体的字体，你也会发现几乎所有的字体都在候选列表中:

$ fc-list | grep 微软雅黑
/home/fengyu/.local/share/fonts/msyhl.ttc: 微软雅黑,Microsoft YaHei,Microsoft YaHei Light,微软雅黑 Light:style=Light,Regular
/home/fengyu/.local/share/fonts/msyh.ttc: 微软雅黑,Microsoft YaHei:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,Normale,Standaard,Normalny,Обычный,Normálne,Navadno,Arrunta
/home/fengyu/.local/share/fonts/msyhbd.ttc: 微软雅黑,Microsoft YaHei:style=Bold,Negreta,tučné,fed,Fett,Έντονα,Negrita,Lihavoitu,Gras,Félkövér,Grassetto,Vet,Halvfet,Pogrubiony,Negrito,Полужирный,Fet,Kalın,Krepko,Lodia

$ fc-match -s 微软雅黑
msyh.ttc: "微软雅黑" "Regular"
msyhl.ttc: "微软雅黑" "Light"
SourceHanSans.ttc: "思源黑体" "Regular"
NotoSans-Regular.ttf: "Noto Sans" "Regular"
NotoSans-Italic.ttf: "Noto Sans" "Italic"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique"
DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique"
verdana.ttf: "Verdana" "Regular"
arial.ttf: "Arial" "Regular"
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
l_10646.ttf: "Lucida Sans Unicode" "Regular"
tahoma.ttf: "Tahoma" "Regular"
NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"
micross.ttf: "Microsoft Sans Serif" "Regular"
cour.ttf: "Courier New" "Regular"
mvboli.ttf: "MV Boli" "Regular"
# ....

但是注意优先级

Answer 2

在字体系统中，一个字体通常不会被直接标记为同时属于serif（衬线）和sans-serif（无衬线）类别，因为这两个类别是互斥的，定义了字体的基本视觉特征。然而，你所遇到的情况可能源于几个不同的因素：

1. 字体样式或版本的不同：在你的例子中，AlibabaPuHuiTi-3-55-RegularL3.otf 和 AlibabaPuHuiTi-3-55-Regular.otf（注意文件名中的微小差异）都被列为了serif和sans-serif的匹配结果。这可能是因为这两个文件名虽然相似，但实际上指向了不同风格的字体文件，或者在某些情况下，字体文件本身可能具有双重分类（尽管这是不常见的）。
2. 字体命名和分类的混淆：字体命名和分类可能因字体设计者的意图、字体文件的元数据或字体管理系统（如fontconfig）的配置而异。在某些情况下，字体可能因设计元素（如某些笔画细节）而被错误地分类或同时出现在多个分类中。
3. fontconfig配置：fc-match 命令使用fontconfig库来匹配字体。fontconfig的配置文件（如fonts.conf、fonts.dir等）可能包含了特定的规则，这些规则决定了如何分类和匹配字体。如果配置文件中存在冲突或不一致的规则，就可能导致类似你所观察到的现象。
4. 字体本身的特性：虽然不常见，但理论上一个字体设计可以在视觉上介于serif和sans-serif之间，或者包含两种风格的元素。然而，这种情况通常不会导致字体同时被明确归类为serif和sans-serif。

解决方案

为了解决这个问题，你可以尝试以下几个步骤：

• 检查字体文件：直接查看字体文件（使用字体编辑器或查看器）以确认其是serif还是sans-serif风格。
• 检查fontconfig配置：查看你的系统上fontconfig的配置文件，特别是与字体分类和匹配相关的部分。
• 更新和重新生成字体缓存：有时，更新字体文件或重新生成fontconfig的字体缓存可以解决匹配问题。
• 联系字体设计者或供应商：如果可能的话，联系字体的设计者或供应商以获取更多关于字体分类和用途的信息。

结论

通常，一个字体不会同时被分类为serif和sans-serif。你所遇到的情况可能是由字体命名、配置错误或字体本身的特性导致的。通过检查这些方面，你应该能够找到问题的根源并解决它。