思源宋体七字重实战:商用授权、格式选择与子集化

发布时间:2026/10/29 20:52:52
思源宋体七字重实战:商用授权、格式选择与子集化

字体这东西,平时没人注意,出事的时候能让人连夜返工。前年冬天我接手一个已经排到终稿的册子,甲方在审版前一天发来一句话:"这个宋体是你们自己买的吗,有没有授权文件?"整个项目三十多页,正文、图注、页眉全用的是一款从素材包里翻出来的宋体,没人说得清它从哪来。结果就是全部正文重新套版,行距、断行、页码联动全部重排,原本两小时能收尾的事拖了整整一天半。这件事之后我给自己定了一条死规矩:凡是商用项目,宋体只从可商用的开源字族里选,而且必须是完整字重、完整字符集、随包附授权文本的那种。思源宋体(TTF/OTF 那一套开源中文字族,英文常写作 Source Han Serif 与 Noto Serif CJK)就是从那之后一直留在我字体文件夹顶部的选择,它一个家族里带七个字重,足够覆盖从封面到脚注的全部层级,也足够撑起一整套视觉体系而不需要再混搭第二款宋体。这篇就把我对这套字族的实际用法摊开讲:七个字重分别该落在什么位置、TTF 与 OTF 与 TTC 到底怎么选、网页端怎么裁到能接受的体积、以及那些装完之后才发现行高跳动、字形回退的坑是怎么一步步查出来的。

1. 把整套项目的宋体收敛到一个字族,这个决定是怎么做出来的

1.1 混搭宋体是设计稿好看、交付要命的典型

很多人排中文版面有个习惯:正文用一款宋体,标题换一款更"有味道"的宋体,引文再用一款仿古的。稿子阶段确实好看,但一旦进入交付环节,问题会成串冒出来。第一款字体可能只有 Regular 和 Bold 两个字重,你想给三级标题一个 Medium,它没有,设计师只能用 Bold 硬顶,视觉层级立刻糊掉;第二款字体的字面大小和第一款差一截,同样 10.5pt,一个显得饱满一个显得干瘦,行首行尾对不齐;第三款字体压根没有配套的西文,中英混排时数字和字母被强行拉去用系统默认字体,一篇文档里出现三种"1"的写法。

我在一个画册项目里被这套组合拳打过一次。当时正文是一款老宋体,标题是一款带手写感的宋体,图注用了第三款。印前打样出来,图注那一款的数字是等宽的,而正文不是,同一页里两组页码宽度差了将近一个字符,版心右侧的视觉边界全是毛的。改的办法只有两个:全部统一,或者给图注单独做一套数字替换。前者成本最低,但要接受"少了一点个性";后者要多花两天。那次我选了前者,并且从那以后所有项目都从一款有完整字重的字族里做横向延展,靠字重和字号拉层级,而不是靠换字族。

收敛到一个字族的好处是可以量化的:字面比例一致,意味着同样的字号下视觉重量可预测;西文与数字同源,意味着混排时基线、x 高度、数字宽度都在一套设计里;字重连续,意味着你能用 200 到 900 之间的连续档位去表达层级,而不必在"太轻"和"太重"之间二选一。这三点加起来,才是"提升效率"的真实来源,而不是单纯省了找字体的时间。

1.2 免费商用这四个字的真实含义,比想象中窄

看到"免费商用"四个字,大部分人的第一反应是"那就可以随便用"。实际操作里,这句话的边界要细得多,我一般会拆成四个问题去核对随包附带的授权文本:

  • 能不能用于商业项目本身?绝大多数开源字族答案是能,没有用户数、项目数、营收规模的门槛。
  • 能不能嵌入到产品里分发?比如把字体打包进一个桌面软件、一个 App、一份可编辑的文档模板。这一条不同字族的条款差异最大,必须逐条看。
  • 能不能修改字形并再发布?通常允许修改,但如果原字族声明了保留字体名,你改完之后就不能继续用原来的名字对外发布,必须改名。
  • 能不能单独售卖字体文件本身?这一条基本都不能,把字体文件本身当作商品卖属于越界。

第三条是最容易踩的。我见过有团队为了去掉某些用不上的字,自己动手改字形文件、重新打包,然后仍然沿用原来的字体名对外分发,这在多数开源授权里是明确不允许的。稳妥做法是:需要裁剪就用工具做子集化输出,不改动原始字形,文件内部名称保持原样;确实要改字形,那就换一个自己的名字,并在随附说明里写清楚来源和改动。

注意:拿到任何一款号称"免费商用"的字体,先别急着装。打开压缩包,找 LICENSE 或 OFL 之类的授权文本,把它和字体文件一起归档进项目资产目录。将来真有人来问,你翻出这个文件就是最省事的回答。

1.3 标题里说的"7款",指的是这套字族的七个字重

很多人被"7款字体"这个说法绕住,以为是七款不同的字体。放到这套开源宋体上,它指的是同一个字族里的七个字重档位:ExtraLight、Light、Regular、Medium、SemiBold、Bold、Heavy,对应数值大致是 200、300、400、500、600、700、900。这七档共用一个骨架、一套字面、一套西文,所以它们之间的组合是"同一句话的不同音量",而不是"七个人在说话"。

这个设计对排版的意义非常大。传统商业字族常常只给你 Regular、Bold、Light 三档,遇到"需要比正文重一点但没到粗体"的位置,你只能靠字号或者颜色去凑,而字号一变,行高和断行全要跟着变。七档字重让你可以保持字号不动,只调字重就把层级做出来,版式骨架完全不受影响。我在做长文档模板时特别喜欢这一点:正文、图注、表头、章标题全部同一个字号或者只差一档,靠字重区分,整份文档的节奏会非常稳。

另外要提醒一句:这七个字重里没有真正的斜体。中文宋体基本都不做斜体字形,软件里那个"斜体"按钮对中文只是把字形做机械倾斜,笔画会变形、重心会歪。要做强调,老老实实用字重或者换颜色,别用伪斜体。

2. 七档字重怎么排兵布阵:从 ExtraLight 到 Heavy 的落位规则

2.1 一张表说清每档字重的适用位置与字号区间

我给自己团队定的规则是:先确定用途,再选字重,最后才调字号。顺序反了就会陷入"字号怎么调都不对"的死循环。下面这张表是我这几年反复修正后的版本,直接可以拿去用:

字重档位数值典型用途建议字号区间建议行高
ExtraLight200大字号封面主标题、留白型海报文字48pt 以上1.15 至 1.25
Light300引文、序言、副标题14pt 至 24pt1.5 至 1.7
Regular400正文、图注、说明文字8.5pt 至 12pt1.7 至 1.9
Medium500小节标题、表头、强调句10pt 至 18pt1.3 至 1.5
SemiBold600二级标题、卡片标题12pt 至 28pt1.25 至 1.4
Bold700一级标题、重点数据16pt 至 40pt1.2 至 1.35
Heavy900封面主标、超大号数字、视觉锤36pt 以上1.1 至 1.2

这张表里最关键的一列是"建议字号区间"。字重越轻,越需要大字号才有存在感;字重越重,字号一大就容易糊成一团黑。ExtraLight 在 12pt 的正文尺寸下几乎看不见,笔画会断在屏幕上;Heavy 在 10pt 的小字里,横画和竖画会粘连,打印出来是一块墨。这两头是新手最容易翻车的地方。

还有一条经验:正文不要低于 Regular。曾经有个项目为了"轻盈感",把整本正文设成 Light,结果读者反馈"看着累"。原因不复杂,小字号下字重过轻,眼睛需要更多努力去补全笔画轮廓,阅读疲劳度会明显上升。轻盈感应该通过留白和行高去做,而不是靠削弱笔画。

2.2 正文、标题、注释的三层映射,别把字重当装饰

一份文档里其实只有三层信息:需要先看到的、需要读完的、需要备查的。三层对应三种字重就够,多出来的层级反而会让人分不清主次。我给的标准映射是这样的:

  • 第一层(标题体系):一级标题 Bold 或 Heavy,二级 SemiBold,三级 Medium。三级之间靠字号递减拉开,字重同步递减,形成从"重而大"到"中而小"的连续过渡。
  • 第二层(正文体系):正文 Regular,正文内强调 Medium,极少数强强调用 Bold。注意正文里的强调不要用 Bold 顶格,因为正文本身就是 Regular,跳到 Bold 落差太大,页面会显得吵;用 Medium 只加一档,读起来是"语气加重"而不是"喊出来"。
  • 第三层(注释体系):图注、脚注、表格内文用 Regular 但降字号,必要时用 Light 配大字号的反向做法。这里有个细节,注释降字号时字重不要跟着降太多,否则小字+轻字重会让它彻底消失,读者找不到注释在哪。

我在做一本产品手册时用过"三级标题全部用 Medium、只靠字号区分"的方案,结果读者反馈层次不够。后来改成 Media 到 SemiBold 的递进,同时把字号差从 2pt 拉大到 4pt,层次立刻清楚了。这说明字重和字号要成对调整,只动一个维度往往不够。

2.3 中英混排时那个"看起来字重不一样"的错觉

中英混排是这套字族用起来最省心的地方,因为七个字重里的西文也是同步设计的,不会出现中文粗、英文细的割裂。但有一种情况要注意:同一档字重下,中文的视觉重量通常比西文重。原因是汉字笔画密度高,同样字号的英文只有一两根笔画,而汉字动辄十几画。所以在一行"促销价 299 元"这种中英数字混排里,数字看起来会偏轻。

我的处理办法有两个。一是把数字单独用高一档的字重,比如中文正文 Regular,数字用 Medium,视觉上就平衡了;二是用字体自带的等宽数字或表格数字特性,让数字在竖向对齐时占位一致。第二个办法在表格里尤其重要,不然一列数字会左右摇摆。

还有个小技巧:中西文混排时,CSS 或者设计软件里的字体列表顺序应该是西文在前、中文在后。这样英文和数字优先命中西文字体,汉字再回退到中文字体。如果顺序反过来,中文宋体里的西文字形会先被命中,那些字形是为全角对齐设计的,混在正文里会显得又宽又扁。

3. TTF、OTF、TTC、可变字体:选错容器格式,体积和渲染都吃亏

3.1 四种容器到底差在哪,什么时候用哪个

同一套字族会以好几种容器格式分发,这不是厂商在凑数,每一种对应不同的使用场景:

  • OTF:基于 PostScript 曲线描述,单文件、单字重。设计软件里兼容性最好,适合桌面排版、印刷输出。缺点是同字符集下体积通常比 TTF 略大。
  • TTF:基于 TrueType 曲线描述,优势在于老系统和部分嵌入式环境的兼容性,Windows 上的老软件、某些打印设备、部分电子书阅读器对 TTF 支持更稳。做通用分发时 TTF 是更保险的选择。
  • TTC:把多个字重或多个语言版本打包进一个文件,共享重复的字形数据。整套七个字重如果各自单独装,系统里会多出七个条目;打成 TTC 之后只占一个条目,体积也能省下相当一部分。适合安装到本机、不希望字体列表被塞爆的场景。
  • 可变字体(Variable Font):一个文件里包含全部字重,通过轴(weight 轴、width 轴)连续调节。网页端用它最划算,一个文件覆盖七个字重;但要注意老版本软件不一定支持,而且同样的字符集下可变字体文件往往比单字重文件大不少。

我的实际组合是这样的:本机装 TTC,一次装完七个字重,字体列表干净;交付给外部协作方时给 TTF 单字重,兼容性最好;网页端做子集化转成 woff2,按字重拆分;只有在需要做动效或者连续字重过渡的项目里才用可变字体。

注意:不要同时装同一字族的 TTC 和单字重 TTF。系统里会出现两个 family name 相同的字体条目,软件里选的时候分不清哪个是哪个,更麻烦的是某些软件会随机命中其中一个,导致同一次导出里字重表现不一致。

3.2 语言子集选错,会出现莫名其妙的字形差异

这套字族按语言区域分了多个版本,简体中文、繁体中文、日文、韩文各有一套,字形骨架相同但部分汉字的写法不同。比如"骨"字的上半部分,简体版和日文版的内部朝向是相反的;"直"字的竖画起笔也有差异。这些差异在做纯中文内容时看不出来,一旦内容里混进了非常用字或者繁体字,就会暴露。

我遇到过一次:一份面向海外华人的宣传页,内容里夹了几个繁体字。因为装的是简体版本,那几个字虽然能显示,但笔画风格和周围不一致,仔细看能看出是另一套字形。解决办法很简单,把繁体版本也装上,在字体列表里按内容语言明确指定,而不是让它自动回退。回退这件事最危险的地方就在于"它能显示",所以你不会去检查,直到有人指出来。

另外一个常被忽略的点是字符覆盖范围。这套开源宋体的字符集覆盖非常广,常用字、次常用字、生僻字、部分扩展区汉字都在里面,这也是它体积大的原因。如果你的项目里有古籍引用、人名用字、方言用字,这一点非常关键。相比之下,很多网络上下载的"精简版"字体砍掉了生僻字,平时看不出来,一到关键位置就露馅——那个字会静默地变成方框,或者回退成系统默认字体,和周围的宋体格格不入。

3.3 网页端不做子集化,首屏会被字体文件拖死

完整的中文字体文件动辄十几兆,直接扔到网页上,移动端用户基本等不到字体加载完就先看到默认字体闪一下,再跳变成宋体,这个体验叫 FOUT,是中文站点最常见的排版事故。处理办法只有一条路:子集化。

子集化的逻辑是把你实际用到的字符抽出来,生成一个小得多的字体文件。中文站点如果只做静态页面,可以把整站文字抓出来去重,通常三千到五千字就能覆盖绝大多数内容,生成的文件能压到几百 KB 甚至更小。如果是内容型站点,无法预知用户会输入什么,那就按字符区间分片,把最常用的三千五百字做一片、次常用字做一片、生僻字单独一片,用字体加载规则里的区间声明去分配,浏览器只会下载命中的那一片。

用 Python 的 fonttools 做子集化,命令大致是这样:

pip install fonttools brotli pyftsubset SourceHanSerifSC-Regular.otf \ --text-file=used-chars.txt \ --flavor=woff2 \ --layout-features='*' \ --output-file=shs-regular-subset.woff2

--flavor=woff2输出 woff2 格式,压缩率最高;--layout-features='*'保留全部排版特性,包括等宽数字、标点挤压这些中文排版很依赖的特性,千万别省。如果你的项目用到了竖排或者标点避头尾,那些特性就在这里面。

输出之后,页面上按字重分别声明:

@font-face { font-family: "SHS-Serif"; src: url("./shs-regular-subset.woff2") format("woff2"); font-weight: 400; font-display: swap; unicode-range: U+3000-303F, U+4E00-9FFF, U+FF00-FFEF; } @font-face { font-family: "SHS-Serif"; src: url("./shs-bold-subset.woff2") format("woff2"); font-weight: 700; font-display: swap; unicode-range: U+3000-303F, U+4E00-9FFF, U+FF00-FFEF; }

font-display: swap是让文字先用回退字体显示,字体加载完再替换,避免白屏。代价是会有一次视觉跳动,所以回退字体要选一个骨架接近的宋体或者通用 serif,别用无衬线去回退,跳变会非常刺眼。

4. 从下载到上线:完整落地链路与每一步的意图

4.1 装之前的准备工作,决定后面会不会返工

下载这一步本身没什么技术含量,但有三个动作必须在安装之前做完。第一,核对文件完整性,把压缩包里的授权文本、版本说明、字符集列表一起解压到一个固定目录,按"字族名-版本号-格式"命名文件夹,这样半年后你还能找到当初装的是哪一版。第二,确认要装哪些语言版本,简体、繁体、日文各取所需,不用的别装,否则字体列表会膨胀。第三,检查机器上有没有旧版本残留,打开字体管理工具或者系统的字体列表,搜一下关键词,把旧的条目先清掉。

这第三步是有教训的。我曾经在同一台机器上装过两个版本的同一字族,版本号只差一个小数点。表面上没事,直到某次导出 PDF 时发现正文里有个别字形的笔画粗细和其他字不一样,排查了半天才定位到是旧版本残留导致软件命中了错误的文件。清干净重装之后问题消失。

装完之后做个验证:新建一个文档,把所有七个字重依次打一遍同一句话,再打一段包含生僻字的文本,看看有没有出现方框。这一步三分钟,能省掉后面几小时的排查。

4.2 设计软件里的设置,行高千万别用"自动"

在排版软件里给正文设字体,最常见的错误是把行高留成自动。中文的行高由字体文件内部的上下度量决定,而不同字族、甚至同一字族的不同格式(TTF 与 OTF),内部度量可能不同,自动行高算出来的值就会不一样。你换一款字体,整页行距就变了,文本块高度跟着变,页码、目录、交叉引用全部要重算。

我的做法是一律显式设定行高数值。正文用字号的 1.7 到 1.9 倍,图注 1.5 倍左右,标题 1.2 到 1.35 倍。数值定死之后,换字体不会动版式,这是长文档项目能稳定迭代的前提。

第二个设置是字符间距和中西文间距。这套字族本身的中西文间距做过优化,一般不需要额外调整,但在小字号下,有些人会手动加一点字距让它"透气"。这里要克制,中文加字距很容易破坏标点的悬挂和对齐规则,尤其在两端对齐的段落里,容易出现某几行字距明显松、某几行明显紧的"流水沟"现象。真觉得挤,优先调行高,而不是调字距。

第三个是标点挤压。中文排版里,连续的标点(比如引号加逗号、书名号加句号)应该压缩占位,不然会出现一段空白。这套字族的排版特性里包含相关规则,前提是你在排版软件里开启了中文排版的对应选项,或者网页端在子集化时保留了排版特性。这一点在正文里不明显,在标题里特别扎眼。

4.3 网页与产品内嵌:授权条款和工程限制要同时满足

网页端用这套字族,除了前面讲的子集化,还要处理两件事。一是字重数量要克制,七个字重全上,即使每个都做了子集化,累加起来的下载量也不小。我的经验是网页端只上三到四个字重:正文 400、正文强调 500 或 600、标题 700,再视情况加一个 300 给引文。剩下的字重在设计稿里用,页面上不加载。

二是加载策略要区分首屏和非首屏。首屏正文用 swap 保证内容先出来,标题这类视觉重量大的元素可以给更长的加载窗口,或者干脆用回退字体,不要为了一个标题字重拖慢整页。

产品内嵌,比如把字体打进桌面软件或者 App,重点在授权和体积。授权层面,多数开源字族的条款允许嵌入分发,但要求随产品附带授权文本,这一点在打包脚本里加个复制动作就解决了。体积层面,产品内嵌可以比网页更激进地裁剪,因为你能确定产品界面用到的字符集有限,通常裁剪后每个字重只剩几百 KB。

有一点必须提醒:不要为了省体积去修改原始字形文件。裁剪用子集化工具做,输出的是新文件,但字形数据本身不改动,文件内部名称也保持原样。一旦你动了字形还沿用原名,就踩到授权里的保留字体名条款了。

4.4 印刷与 PDF 导出:字体嵌入必须逐项确认

印刷环节最大的风险是字体没嵌进去。桌面上看着好好的,送到印厂打开发现字体被替换成了默认宋体,整个版式全乱。这件事我自己遇到过两次,一次是导出 PDF 时没勾选嵌入,一次是某个字重用了系统里另一个同名文件。

规避方法很朴素:导出 PDF 后,打开文档属性里的字体列表,逐个核对。所有用到的字重都应该显示为"已嵌入"或"子集嵌入",如果某个字重显示为未嵌入,或者显示成了别的字体名,立刻回头查。另外,子集嵌入时如果文档里有动态内容(比如表单域、可编辑字段),子集化可能漏掉用户后续输入的字符,这种情况下要改成完整嵌入。

还有一个和印刷相关的细节:这套字族的笔画比较细腻,在低分辨率打印或者小字号下,细笔画容易断。如果项目最终是胶印,字号不要低于 7.5pt;如果是数码打印,可以到 8pt;如果只是屏幕阅读,7pt 也能接受。这个数字不是绝对的,和纸张、油墨、设备都有关系,但作为起始参考足够用。

5. 踩坑排查实录:字形回退、行高跳动与跨平台差异

5.1 出现方框或者字体突变时,按这个顺序查

屏幕上突然冒出一个方框,或者某个字明显不是宋体,这类问题我摸索出一套固定的排查顺序,基本五分钟内能定位:

  1. 先确认那个字是什么。把光标放上去,看字符编码。有些"字"其实是特殊符号、异体字、或者从别处粘贴来的兼容字符,不在字体覆盖范围内。
  2. 再确认当前文字套用的字体样式。很多软件里字体是按段落样式和字符样式分层的,你以为全局是宋体,但某个字符样式里覆盖成了别的字体。
  3. 然后确认安装状态。字体是否真的装好了,是不是装了个残缺版本。用系统的字体列表确认字重数量对不对。
  4. 最后看语言版本。如果那个字是繁体或者日文汉字,而装的是简体版本,虽然能显示,但字形风格不一致,这种情况不算方框,但属于同一类问题。

我在一个跨平台项目里被第四种情况坑过。同一份稿件,在简体环境下排版正常,换到繁体环境下打开,有几个字的字形变了,导致该行变宽,断行位置整体位移了半个字。这类问题在交付前用不同语言环境的机器各开一次就能发现,成本很低。

5.2 行高莫名跳动,九成是内部度量不一致

这是中文排版里最隐蔽的一类问题:同一段文字,什么都没改,只是换了个字重或者换了个格式,行高就变了。根本原因在于字体文件内部的上下度量值不同,而排版软件的"自动行高"是依据这些值算的。

诊断方法很直接:把行高改成固定数值,看跳动是否消失。如果消失了,就确认是度量问题,以后一律用固定行高。如果没消失,那问题在别处,通常是段落间距、网格对齐、或者文本框的自动缩放被打开了。

还有一种情况是混排导致的。同一行里既有中文又有西文,如果中西文来自不同字族,而两个字族的度量不同,行高会按其中较高的那个算,于是这一行比周围的行高出一截。解决办法是让中西文来自同一字族,或者显式设定一个能容纳两者的大行高,让所有行统一。

5.3 同一份文件在两种系统上打开,为什么行数和分页都不一样

跨平台渲染差异是所有做长文档的人都会遇到的老问题。同一份文件,在一个系统上排出来是 32 页,换一个系统打开变成 33 页,最后一页只有两行。原因通常有三层:字体文件版本不同、文字渲染引擎的舍入规则不同、以及度量计算的精度差异。

第一层最好解决,统一字体版本,项目资产里锁死一份字体文件,所有人都装这一份,不要各自去网上下载。第二层只能规避,不要在临界状态下排版——比如让一页的内容刚好占满到毫米级,那换台机器必然溢出,留出 5% 到 8% 的余量。第三层涉及精度,某些引擎在把字体单位换算成物理尺寸时,小数位的处理方式不同,累积到几十行之后会产生可见差异,这个没法彻底消除,只能靠留余量吸收。

我的做法是:所有对外交付的长文档,在目标打开环境里做一次最终校验,而不是在自己机器上看着没问题就发出去。如果文档要在多个环境里被打开,那就把版式做得更"抗造"一点——行高用整数、字号用整数、页边距留出缓冲。

6. 授权边界与团队协作:把字体当成项目资产来管

6.1 "免费商用"要在团队里被写成规则,而不是口口相传

一个团队里,字体出问题的概率和人员流动率是正相关的。老人知道哪款能用,新人不知道,从素材站随手下一款就用了。所以"免费商用"这件事必须在团队内部变成一条可执行的规则,而不是一句口头共识。

我推行的做法是建一个字体资产目录,每个字族一个子目录,里面固定放四样东西:字体文件本身、授权文本、来源与版本说明、以及一份"允许用途"的简短备注。任何人在项目里要用字体,只从这个目录里取,不许从网上临时下载。新项目启动时,字体清单跟着设计规范一起交付,谁用了目录外的字体,评审时直接打回。

这套流程听起来有点重,但实际执行下来,它省掉的是返工和扯皮。前面提到的那个封面重排,如果有这套流程,压根不会发生——因为素材包里那款来路不明的宋体根本进不了目录。

6.2 交付物里要不要带字体文件,这个决定要提前做

给客户交付源文件时,一个常见争议是:字体文件到底要不要一起给。给的顾虑是字体被二次分发,不给的后果是客户打开源文件看到字体缺失、版式错乱,然后回头找你。

我的处理方式分三种情况。如果交付的是印刷用的 PDF 或者图片,字体已经嵌入或栅格化,源文件不必附带字体,但要在交付说明里写清楚用的哪款字体、什么版本,方便对方后续修改时安装。如果交付的是可编辑的源文件(设计稿、文档模板),那就要把字体一起打包,并且在说明里注明授权范围和再分发限制。如果交付的是产品内置字体,那就按授权要求附带授权文本,并在产品的关于页面或者许可页面里列出来。

有一点容易被忽略:即使是可商用的开源字体,把它单独打包发给客户,和把它嵌在产品里,性质是不一样的。前者相当于你在分发字体文件本身,后者是嵌入使用。多数开源授权对这两种情况都允许,但要求随附授权文本,所以最省事的做法是打包时把授权文本一起放进去,不要嫌麻烦。真到了需要解释的时候,这份文件比任何口头说明都管用。

字体这件事,说到底不是选一款好看的字体,而是把一套可控、可复现、可交付的排版基础搭起来。七个字重给我的是层级表达的自由度,多种容器格式给我的是不同场景下的适配能力,而随包的那份授权文本,给我的是项目做完之后还能睡个安稳觉的底气。我现在每开一个新项目,第一步不是打开设计软件,而是先把字体目录里那几个文件复制到项目文件夹,顺手把授权文本也拖进去。这个动作花不到一分钟,但它把后面所有的返工风险都提前挡掉了。