/* ═══════════════════════════════════════════════════════════════════════ CERYE 字体系统 · pro-type.css （手写，字体栈与渲染细节） 配套文件：assets/pro-fonts..css 由 tools/build-fonts.py 生成， 里面只有 @font-face，文件名带内容 hash，走 immutable 长缓存，不要手改。 本文件只有几 KB，跟着 .css 的 no-cache 走，改版式改这里。 两个文件都要在 site.css / pro.css 之后加载。 ── 一条更正，放在最前面 ──────────────────────────────── 我最初是按「大陆访问不到 Google Fonts」来做这件事的。这条不成立。 实测（杭州阿里云服务器，真实国内网络）： fonts.googleapis.com/css2?family=Noto+Serif+SC -> HTTP 200, 0.14s 从返回的 CSS 里抠出真实 woff2 地址直接下载 -> HTTP 200, 2772 字节 字体是真的下得来的。所以「客户看到的是宋体」这个说法是错的， 不要再按这个理由跟别人解释。 ── 那为什么还要自托管：一条硬理由，两条软的 ──────────── 一、载荷差 5 倍。同样八个页面、同样视口、同样滚动、都不吃缓存： 现状（Google Fonts） 每页 1871 到 3546 KB，八页合计 21.9 MB 自托管 每页 402 到 668 KB，八页合计 4.2 MB 差距不在切片质量，在字重。页面 head 那行 css2 请求了 7 档中文字重 （Noto Serif SC 的 400/500/600/700 + Noto Sans SC 的 300/400/500）， Google 给每一档单独切 101 片，一共下发 732 条 @font-face； 浏览器要渲染一个字，就得为每一档各下一片。 我们用可变字体，一份文件字重连续覆盖，字重这个维度不再乘系数。 顺带一提：全站实际只用 400/500/600 三档，另外四档一直在白付流量。 二、少一个第三方依赖。服务器路由好不等于每个客户都通， Google Fonts 在大陆历史上时好时坏。可靠性问题，不是可用性问题。 三、回退链原来没写具名字体。这条收益不大，实话说清楚： 没加载上时掉进通用 serif，Windows 上就是 SimSun， 而 SimSun 在 76px 下并不难看，是偏细偏古典的宋体，能读、有味道， 只是比 Noto Serif SC 单薄。这是审美差距，不是显示故障， 我之前把它说成「又细又飘、吸引不了人」是夸大了。 ── 字体与授权 ────────────────────────────────────────── 五族全部 SIL Open Font License 1.1，明确允许修改、子集化、网页嵌入 与随作品分发。五份 OFL 全文在 assets/fonts/ 里随字体分发， 字体文件的 name 表也保留了版权声明与授权网址，这两条就是 OFL 的全部要求。 中文正文 Noto Sans SC 可变字重 400-700 中文衬线 Noto Serif SC 可变字重 400-600 西文正文 Inter 4.x 300-700 西文衬线 Fraunces 正体加斜体 400-600 等宽 IBM Plex Mono 400 / 500 / 600 没选华为 HarmonyOS Sans：它声明免费商用，但授权条款对「修改字体文件」 有限制，而我们必须做子集化，子集化在法律上就是修改。这个风险不该老板担。 site.css 原本指定的 Archivo 用 Inter 顶替，因为 Inter 与 Noto Sans SC 的字面高度几乎完全对得上（大写高 0.728 对 0.733 em，小写 x 高 0.546 对 0.543 em），中英混排不会一高一低，所以本文件里不需要任何 size-adjust 去硬拗。 ═══════════════════════════════════════════════════════════════════════ */ /* ── 兜底字体的度量对齐 ──────────────────────────────────── 网络字体下载完成的那一刻会发生替换。顶上的系统字如果纵向度量不一样， 整段文字会跳一下。微软雅黑的 hhea 是 1.058/-0.262， 我们的 Noto 是 1.000/-0.200，差了 0.12 em。 这里把系统字包一层，强制用同一组纵向度量，替换时就不跳。 注意这里故意不写 size-adjust：汉字的前进宽度两边都是 1em， 一旦缩放反而会造成横向回流，得不偿失。 */ @font-face{ font-family:"Cerye SC Fallback"; src:local("PingFang SC"),local("Microsoft YaHei"),local("HarmonyOS Sans SC"), local("Noto Sans CJK SC"); ascent-override:100%;descent-override:20%;line-gap-override:0%; } :root{ /* ── 无衬线（正文）──────────────────────────────────── 从左到右每一项都在回答同一个问题：这台设备上最好的选择是什么，能不能不花流量。 1. -apple-system / BlinkMacSystemFont 苹果设备直接拿到真正的 SF Pro。老板说的「苹果的字体」就是它， 系统自带，一个字节不用下，在 macOS 上的渲染没有网络字体追得上。 2. "Cerye Latin"（自托管 Inter） 非苹果设备的西文。这里故意不写 system-ui：Windows 上 system-ui 会解析成 Segoe UI，而 Segoe 的字面比例跟中文字体对不齐。 3. "PingFang SC" 苹果设备的中文，苹方，系统自带。放在自托管中文之前， 苹果用户因此一片中文分片都不会下载。 4. "Noto Sans CJK SC" 安卓与多数 Linux 的系统中文，和我们自托管的是同一款字， 能匹配上就省掉整包下载，效果完全一致。 5. "Cerye SC"（自托管 Noto Sans SC 子集） Windows 走这一条，也是唯一真正花流量的一条，所以做了分片。 6. 其后 网络字体还在路上、或者万一加载失败时的本地兜底。 这里只是引用本机已装好的字体，不涉及分发，没有授权问题。 */ --sans:-apple-system,BlinkMacSystemFont,"Cerye Latin", "PingFang SC","Noto Sans CJK SC","Cerye SC","Cerye SC Fallback", "HarmonyOS Sans SC","Microsoft YaHei",sans-serif; /* pro.css 用的是 --font 这个名字，值保持一致，两套样式表共用同一套字 */ --font:var(--sans); /* ── 中文衬线（site.css 的 --cn，站内所有大标题）──────── 原值是 "Noto Serif SC",serif，而 Noto Serif SC 只从 Google Fonts 加载， 大陆拿不到，于是 .hero h1 那个 clamp(44px,8.5vw,118px) 的首屏大标题 实际掉到通用 serif，在 Windows 上就是宋体。 SimSun 在大字号下并不难看，只是偏细偏古典，比 Noto Serif SC 单薄； 真正的问题不在这里，在载荷（见文件头第一条）。现在换成自托管的子集。 西文排在中文之前，这样标题里的英文走 Fraunces，跟中文衬线是一套调子。 */ --cn:"Cerye Serif","Cerye Serif SC", "Source Han Serif SC","Noto Serif CJK SC","Songti SC","STSong","SimSun",serif; /* ── 西文衬线（site.css 的 --en）──────────────────────── */ --en:"Cerye Serif",Georgia,"Times New Roman",serif; /* ── 等宽 ────────────────────────────────────────────── 末尾必须接中文兜底：实测有 665 个汉字落在等宽族上， 原来的栈到 monospace 就断了，那些汉字会掉到浏览器默认字体， 跟正文不是一套。 */ --mono:"Cerye Mono",ui-monospace,SFMono-Regular,"SF Mono",Menlo,Consolas, "Cerye SC","PingFang SC","Microsoft YaHei",monospace; /* 字重只用这三档。600 而不是 700：700 的汉字在正文字号下笔画会糊在一起， 而且显得廉价。苹果自己的中文大标题用的也是 Semibold，不是 Bold。 */ --fw-text:400;--fw-medium:500;--fw-semibold:600; } body{ /* 关掉次像素渲染换成灰度抗锯齿。苹果在 apple.com 上就是这么做的， 字形边缘更干净，大字号尤其明显。两套样式表里本来都有，这里统一。 */ -webkit-font-smoothing:antialiased; -moz-osx-font-smoothing:grayscale; font-kerning:normal; /* 中英混排：在汉字与西文、汉字与数字之间自动插入约 1/8 个字宽的气口。 「共 12 款香型」里的 12 两边本来就该有间隙，这是中文排版里最容易 被忽略、但一眼能看出差别的一条。目前只有较新的 Chrome 实现， 其余浏览器直接忽略，不会报错也不会变形。显式写出来一是表明意图， 二是防止将来浏览器改默认值。 */ text-autospace:normal; /* 我们提供了真实字重，不需要浏览器再合成假粗。 合成粗体在汉字上会把笔画糊成一团，比真 600 难看得多。 */ font-synthesis-weight:none; } /* text-rendering 这里刻意不设 optimizeLegibility。 它在中文字体上会强制启用一批本来就开着的特性，收益是零， 但在几千字的目录页上会明显拖慢排版。 真正需要的字距，font-kerning:normal 已经给了。 */ /* ── 数字 ────────────────────────────────────────────────── 正文里用比例数字读起来自然，凡是要上下对齐的地方一律等宽数字。 数字不对齐是表格显廉价的头号原因。 */ table.t td,table.t th,time,.price,.qty,.amount,.specsheet .sv{font-variant-numeric:tabular-nums} /* ── 字重归一 ────────────────────────────────────────────── 与 浏览器默认是 700。整套视觉语言用的是 600， 放任 700 会在正文里冒出一档更重的灰度，层次就乱了。 两套样式表里更具体的选择器（.tip b / .nav-tier b / .stat b 等）不受影响。 */ strong,b{font-weight:var(--fw-semibold)} /* ── 小工具 ──────────────────────────────────────────────── 纯西文的展示字串（词标、大号数字）可以收得比中文更紧。 中文大标题不能用这么紧的字距：汉字本来就是满格方块， 收过头笔画会贴到一起，所以这一档只给纯西文用。 */ .lat-tight{letter-spacing:-.04em;font-feature-settings:"case" 1} /* 全角标点的留白，实际渲染对比过四种做法（截图存档在 scratchpad/shots/punct.png）： A space-all 不收，「（」「）」「：」两边各空一个字宽，松散 B normal Chrome 的默认值，括号与冒号收紧，效果已经很好 C trim-start 和 B 肉眼没有差别 D palt 字体特性 连顿号与逗号一起压窄，偏紧，像日文杂志，不符合中文习惯 结论：Chrome 默认（B）就是最好的，所以全局不做任何设置。 Safari 与 Firefox 还没实现 text-spacing-trim，会是 A 那样偏松的样子， 这是目前浏览器的现状，只能等。下面两个类留给需要手动调的区块，不做默认。 */ .trim-punct{text-spacing-trim:trim-start} .tight-punct{font-feature-settings:"palt" 1} /* 本文件没有任何动效。若后续在此加过渡，必须遵守： */ @media(prefers-reduced-motion:reduce){ *{animation-duration:.01ms!important;transition-duration:.01ms!important} }