科技报告字体调整：西文改 Cochineal、标题统一鸿蒙、代码换等宽 #19

用户反馈「标题一会儿黑体一会儿什么体的」。pymupdf 提取旧 PDF 定位到
三处字体分裂，逐条修掉。

一、西文从鸿蒙换成 Cochineal（cls/font.cls）

旧版 \setmainfont / \setsansfont / \setmonofont 三处全是鸿蒙。中文换成
思源宋体之后，正文就成了「中文衬线 + 西文无衬线」：同一行里英文数字比
汉字细、像陷进去，读起来割裂。

Cochineal 是 Minion 风格的衬线体（OFL 1.1，fonts/cochineal/ 已在库内），
与思源宋体灰度接近；度量与 Termes 只差 1.9%，不推着断行变。

\setsansfont 保持鸿蒙 —— 标题靠 \hm 切到 OUCHM 族，西文 sans 位仍是鸿蒙，
标题的中西文因此都是鸿蒙，与正文区分得开。

二、\hm 重定义为中西文一起切（cls/font.cls，本次核心）

这是「字体一会儿一个样」的真正来源。fonts.tex 里的 \hm 是
    \def\hm{\CJKfamily{OUCHM}}
纯 xeCJK 中文字族切换，管不到阿拉伯数字和拉丁字母。而标题、封面主标题、
摘要标题都用 \hm 表示「这是鸿蒙」，于是凡是标题里夹了西文就还是西文字体：

  · 章节编号 "1." "3.1" → 走 \setmainfont → 旧版是鸿蒙粗，改 Cochineal 后
    变成衬线粗，与中文鸿蒙粗并排
  · "这是一个很好用的 LaTex 模板" 里的 LaTex → 走 \setmainfont
  · 目录条目编号是数字、标题是中文 → 同一条目录两种字体

修法：本模板内把 \hm 重定义为 \hmlatin\CJKfamily{OUCHM}，中西文一起切。
一次在源头解决，不在每个调用点补 \hmlatin —— 后者必然漏（封面、摘要、
目录标题、页眉、文本框标题各漏一次，本次实测漏了 4 处）。

不改 ../fonts.tex 的 \hm：幻灯片和简历也在用，它们没有这个问题，全局改
会外溢。

三、目录条目与页码归零（cls/title.cls）

\cftsecfont 等三条只管条目文字，页码走 \cft*pagefont，不显式清掉的话
目录里页码比标题还粗、最抢眼。两组共 6 条一起设 \normalfont。
不塞 \bfseries：加粗与否是各条目录自己的事，硬加会让二三级也变粗。

四、代码等宽位换 Latin Modern Mono（cls/font.cls）

旧版 \setmonofont 也是鸿蒙 —— 它不是等宽字体，代码里 i/l/1、m/w 宽度
不一，竖向对不齐、缩进看着是歪的。lmmono 是 TeX Live 自带，无需额外
字体文件。

⚠️ 这里不能用 Extension + UprightFont=*-regular：lm 系列文件名本身是
"lmmono10-regular.otf" 已带 -regular，再拼会变成 lmmono10-regular-regular
然后报 cannot be found。给完整文件名、不给 Extension。粗体用
lmmonolt10-bold（同族等宽，换粗体不错位），没有 lmmonobq 这个变体。

五、内容块保留 3 个 Underfull（cls/boxes.cls，只加注释不改代码）

第 208/214/220 行的 \verb|Illuminate\Foundation\Http\Kernel| 是 35 字符
不可断串，在内容块 371pt 内宽里塞不下。试过无效的：\emergencystretch
2em/10em（不是额度不够，是这行没有足够可拉伸 glue）、\sloppy（badness
从 1231 升到 3590，更差）。有效但不采用：\seqsplit（归零但任意字符处
断行，代码路径被切两段）、窄体 lmmonoltcond（归零但压缩可读性）。

结论：保留这 3 个，badness 1231 属轻微（10000 才是严重），渲染只是行末
留白略多。日志里看到它们属预期，不是回归。

六、report.tex 字体说明同步

第 52/58 行原文说「英文字体默认使用鸿蒙」，改后已不准确，重写为
Cochineal + Latin Modern Mono 的实际状况，并说明标题编号统一的原因。

验证（两套环境各跑两遍，逐字同数）

  WSL / TeX Live 2025：rc=0，error 0，Overfull 0，Underfull 4，10 页
  Windows / TeX Live 2022：rc=0，error 0，Overfull 0，Underfull 4，10 页

pymupdf 提取字体分布，两侧完全一致：
  Cochineal-Roman 782   OUCSerif-Regular 143   LMMono10-Regular 98
  OUCKai-Regular 33     HarmonyOS_Sans_SC_Bold 22   HarmonyOS_Sans_Bold 14
  OUCSerif-Bold 8       FontAwesome 5   HarmonyOS_Sans_SC 3
  ZhuqueFangsong 2      OUCSans-Regular 2   CMSY10 1   CMEX10 1
  HarmonyOS_Sans 1

标题逐页核对（中西文双档均属鸿蒙）：
  p1 封面   HarmonyOS_Sans_SC_Bold「这是一个很好用的」+ HarmonyOS_Sans_Bold「LaTex」
  p2 目录   HarmonyOS_Sans_SC_Bold「目录」
  p5 摘要   HarmonyOS_Sans_SC_Bold + HarmonyOS_Sans_Bold「LaTex」
  p6 正文   HarmonyOS_Sans_Bold「1.」+ HarmonyOS_Sans_SC_Bold「准备工作」
  p10 正文  HarmonyOS_Sans_Bold「8.」+ HarmonyOS_Sans_SC_Bold「图标」

OUCSans-Regular 2 / ZhuqueFangsong-Regular 2 / HarmonyOS_Sans 1 三处少量
命中已逐个查清，都不是回归：
  · p6「黑体」「仿宋」—— 正文故意演示 \fzzdx / \fzfs 的示例文字
  · p8 每页同 bbox、45° 旋转、29.8pt —— 全页水印，设计如此
  · p10「HTTP/Console」—— 文本框标题走 fonttitle=\hm，改后已是
    HarmonyOS_Sans + HarmonyOS_Sans_SC，中西文都属鸿蒙

涉及文件：
  科技报告/cls/font.cls    默认族、\hm 重定义、等宽位
  科技报告/cls/title.cls   目录条目与页码归零
  科技报告/cls/boxes.cls   仅补 Underfull 记录注释，代码未改
  科技报告/report.tex      字体说明文字同步

科技报告/cls/boxes.cls

@@ -6,6 +6,27 @@
 % 颜色一律引用 cls/color.cls 里的语义名（oucinfo / oucalert ...），
 % 不在这里写具体色名，更不写 RGB 值。
 %
+% 【关于内容块里的 3 个 Underfull \hbox（#19 记录）】
+%
+% 第 208/214/220 行那三段示例文字里有 \verb|Illuminate\Foundation\Http\Kernel|，
+% 这个 35 字符的串在 \verb 里**不能断行**，整行只能把它塞进去，于是那行
+% 被撑松 —— 报 Underfull (badness 1231)。
+%
+% 试过且**无效**的方案（别重复踩）：
+%   · \emergencystretch 2em / 10em —— 无效。它不是"额度不够"的问题：
+%     这一行没有足够的可拉伸 glue 可用，给多少额度都无从施展。
+%   · \sloppy —— 反而更差，badness 从 1231 升到 3590（放宽了断行标准，
+%     TeX 选了别的更松的解）。
+%
+% 有效但**不采用**的方案：
+%   · \seqsplit —— Underfull 归零，代价是在任意字符处断行，
+%     一条代码路径被切成两段，可读性明显变差。
+%   · 换窄体等宽 lmmonoltcond（Light Condensed）—— 也归零，
+%     但压缩字体让代码变窄变小，为一个示例文本牺牲整体代码可读性不合理。
+%
+% 结论：保留这 3 个 Underfull。badness 1231 属轻微（10000 才是严重），
+% 渲染出来只是行末留白略多，不影响阅读。日志里看到它们属预期，不是回归。
+%
 
 %% 带标题的文本框
 % 这个框走的是"极简"路线：框线和标题栏都是白色，靠黑字 + 细边分界。