这批二创是我照着同一条路做的。合集叫「原神纳塔斯瓦希里语二创歌曲」，25 首，从 2025 年 5 月做到 2026 年 6 月，总长 93 分钟，播放加起来 23 万次。合集自己的说明是「原创或者重新填词的斯瓦希里语歌曲」。斯瓦希里语的歌词是我自己填的，演唱是合成的。
这 25 首不是同一个主题下的变奏。立意分几路：
前三路都在正面处理纳塔的主线：牺牲、功绩、传承。第四路换了个壳子，把同样重的东西装进一个荒诞的画面。这个二创在华语玩家中间本来就流传，拿它当容器，反而让「她一个人扛下了什么」这句话容易出口。
四路不能被压成一句话。把它们的主题并成一个说法，每一首都会被读错。
列举部分歌曲的原曲。左边是原曲，右边是这一版：
《如愿》与《怀念战友》两首连题名都没换。改动最轻的是《错位时空》，只动了一个字。
25 首里，玛薇卡占 12 首。茜特菈莉与希诺宁各 2 首，玛拉妮 1 首。剩下 8 首不点角色名，写的是纳塔这个国家本身。
有两首配的是游戏里搭出来的景：一首对着纳塔英雄纪念碑与公墓，一首对着一座金字塔。游戏里能搭的东西有限，所以这两首更像是在替某处地点配一首它本来就该有的歌。
合集与第一首都在 B 站：https://www.bilibili.com/video/BV1FbVf6vEFA
23 万次播放不算多，但这批东西是 25 首完整的歌，用一门外语，为一个游戏地区，做了十三个月。
]]>这批二创是我照着同一条路做的。合集叫「原神纳塔斯瓦希里语二创歌曲」，25 首，从 2025 年 5 月做到 2026 年 6 月，总长 93 分钟，播放加起来 23 万次。合集自己的说明是「原创或者重新填词的斯瓦希里语歌曲」。斯瓦希里语的歌词是我自己填的，演唱是合成的。
这 25 首不是同一个主题下的变奏。立意分几路：
前三路都在正面处理纳塔的主线：牺牲、功绩、传承。第四路换了个壳子，把同样重的东西装进一个荒诞的画面。这个二创在华语玩家中间本来就流传，拿它当容器，反而让「她一个人扛下了什么」这句话容易出口。
四路不能被压成一句话。把它们的主题并成一个说法，每一首都会被读错。
列举部分歌曲的原曲。左边是原曲，右边是这一版：
《如愿》与《怀念战友》两首连题名都没换。改动最轻的是《错位时空》，只动了一个字。
25 首里，玛薇卡占 12 首。茜特菈莉与希诺宁各 2 首，玛拉妮 1 首。剩下 8 首不点角色名，写的是纳塔这个国家本身。
有两首配的是游戏里搭出来的景：一首对着纳塔英雄纪念碑与公墓，一首对着一座金字塔。游戏里能搭的东西有限，所以这两首更像是在替某处地点配一首它本来就该有的歌。
合集与第一首都在 B 站：https://www.bilibili.com/video/BV1FbVf6vEFA
23 万次播放不算多，但这批东西是 25 首完整的歌，用一门外语，为一个游戏地区，做了十三个月。
]]>一个扫 ARMv5TE 汇编，一个扫 Pentium 与 pre-P6（P5、Cyrix、K6）以及 Pentium 4 的 x86 汇编。
它们找的是在目标 CPU 上划不来的序列。只要划不来就值得看一眼，指令条数多少不是重点。
判据不靠个人经验，全部锚在 gcc 的权威源上，分三类：
gcc/config/i386/x86-tune.def 里的 X86_TUNE_* 标志，那些「避开某条指令」的条目。工具输出一份清单，不直接判定失败。
同一条指令在目标 CPU 上更贵，不等于这段代码就该改。改写要证明的东西在工具看不到的地方：改完之后原来被依赖的标志位是不是已经死了，对齐是不是还成立，时序有没有被别的指令补上。这些只有读代码的人能证明。
所以两个 linter 都是普查，不是闸门。报告「看这里」，判断留给读的人。
例外有两处，都在 ARM 那个里：--isa 是 ISA 门，-a 里的 Extended Asm 契约检查也算。这两处不存在权衡。指令集里没有的指令，或者写错的约束契约，就是错，没有可商量的余地。
每个 linter 自成项目，彼此不共享代码。Python，加一张模式规则表，加两组测试：单元测试用合成的指令序列，集成测试用真实反汇编夹具。各自带 Makefile 与 pyproject.toml。
两个脚本各自在自己的目录里跑：
1 | python3 armv5telint.py arm.dis |
两个目录各自 make test，跑全部模块的测试。
项目在 https://github.com/lunzima/potatolint，许可 MIT。代码与文档里出现的处理器、架构与设备名称是各自所有者的商标。
]]>一个扫 ARMv5TE 汇编，一个扫 Pentium 与 pre-P6（P5、Cyrix、K6）以及 Pentium 4 的 x86 汇编。
它们找的是在目标 CPU 上划不来的序列。只要划不来就值得看一眼，指令条数多少不是重点。
判据不靠个人经验，全部锚在 gcc 的权威源上，分三类：
gcc/config/i386/x86-tune.def 里的 X86_TUNE_* 标志，那些「避开某条指令」的条目。工具输出一份清单，不直接判定失败。
同一条指令在目标 CPU 上更贵，不等于这段代码就该改。改写要证明的东西在工具看不到的地方：改完之后原来被依赖的标志位是不是已经死了，对齐是不是还成立，时序有没有被别的指令补上。这些只有读代码的人能证明。
所以两个 linter 都是普查，不是闸门。报告「看这里」，判断留给读的人。
例外有两处，都在 ARM 那个里：--isa 是 ISA 门，-a 里的 Extended Asm 契约检查也算。这两处不存在权衡。指令集里没有的指令，或者写错的约束契约，就是错，没有可商量的余地。
每个 linter 自成项目，彼此不共享代码。Python，加一张模式规则表，加两组测试：单元测试用合成的指令序列，集成测试用真实反汇编夹具。各自带 Makefile 与 pyproject.toml。
两个脚本各自在自己的目录里跑：
1 | python3 armv5telint.py arm.dis |
两个目录各自 make test，跑全部模块的测试。
项目在 https://github.com/lunzima/potatolint，许可 MIT。代码与文档里出现的处理器、架构与设备名称是各自所有者的商标。
]]>这个项目是一套全拼词典，覆盖单字到长词组。词频不来自单一词表，而是多个互相独立的来源融合校准而成。清洗、去冗余、离群点检测与合并的完整做法单独写在一份文档里，不藏在脚本里。
引擎吃的格式不一样，所以按引擎分发。
pinyin.dict.yaml，全量约 53.4 万条。精简版是 pinyin_lite.dict.yaml，约 23.6 万条。pinyin_fcitx5.dict，对应全量版。pinyin_lite_fcitx4.mb，对应精简版。dict.txt，约 52.5 万条。预编译那两份的意义是省掉一次编译。fcitx 用户拿到就能用，不需要在本机把词表重新编一遍。
dict.txt 的词频是浮点数，dict_intrank.txt 的内容一致，词频是整数。
浮点词频能表达更细的名次差别，但不是每个引擎都收。采用整数词频机制的输入法只认排名，喂浮点数会被截断或拒绝。分成两份，是为了不让人自己去换算，也避免换算时按错误的方式取整。
纯文本那两份只收两字以上的词组，单字只在 Rime 的源码词典里。
它们的定位是增补词库，不是基础词库 —— 基础词库里的单字够用，这里只补词组。
需要逐字输入的场景用 Rime 那两份，只要词组排序的场合用文本那份。
按自己用的引擎挑一个文件。Rime 用户把 .dict.yaml 放进用户目录重新部署；fcitx5 与 fcitx4 直接用预编译文件。想自己导入的，先看清目标软件收浮点还是整数词频，再选 dict.txt 或 dict_intrank.txt。
项目在 https://github.com/lunzima/ChsPinyinUDL，许可 MIT。词典的更新频率不会很高，问题与词汇建议走 issue 即可。
]]>这个项目是一套全拼词典，覆盖单字到长词组。词频不来自单一词表，而是多个互相独立的来源融合校准而成。清洗、去冗余、离群点检测与合并的完整做法单独写在一份文档里，不藏在脚本里。
引擎吃的格式不一样，所以按引擎分发。
pinyin.dict.yaml，全量约 53.4 万条。精简版是 pinyin_lite.dict.yaml，约 23.6 万条。pinyin_fcitx5.dict，对应全量版。pinyin_lite_fcitx4.mb，对应精简版。dict.txt，约 52.5 万条。预编译那两份的意义是省掉一次编译。fcitx 用户拿到就能用，不需要在本机把词表重新编一遍。
dict.txt 的词频是浮点数，dict_intrank.txt 的内容一致，词频是整数。
浮点词频能表达更细的名次差别，但不是每个引擎都收。采用整数词频机制的输入法只认排名，喂浮点数会被截断或拒绝。分成两份，是为了不让人自己去换算，也避免换算时按错误的方式取整。
纯文本那两份只收两字以上的词组，单字只在 Rime 的源码词典里。
它们的定位是增补词库，不是基础词库 —— 基础词库里的单字够用，这里只补词组。
需要逐字输入的场景用 Rime 那两份，只要词组排序的场合用文本那份。
按自己用的引擎挑一个文件。Rime 用户把 .dict.yaml 放进用户目录重新部署；fcitx5 与 fcitx4 直接用预编译文件。想自己导入的，先看清目标软件收浮点还是整数词频，再选 dict.txt 或 dict_intrank.txt。
项目在 https://github.com/lunzima/ChsPinyinUDL，许可 MIT。词典的更新频率不会很高，问题与词汇建议走 issue 即可。
]]>它们的共同点是能力窄：复音数在一到九之间，没有力度曲线，音源严格照谱发声。现代软音源会掩盖的问题，在这些设备上全都听得见，因此只能在写谱阶段处理，回放阶段无法补救。
parlour arrangement 的旧义就是这个意思：把熟悉的曲子改编到家中那件乐器能演奏的程度。
复音数指同时发音的上限。每首曲子标注的是实测峰值，即一台设备播完整首曲子所需的同时发音数。
每首曲子是一个 Python 脚本，谱面作为字面数据写在源码里，不用 MIDI 库，也没有编辑器工程。运行脚本会在 output/ 下逐字节复现那个文件。
曲子用于循环播放，配在其他内容底下。音效不循环，半秒左右播完，单独收听，因此另放一个目录。
midi_check.py 把文件的问题分成两类。
midi_stats.py 只计数与测量，不做判断。
复音预算和最短音符长度都可以从命令行给定，便于按目标设备复核。
编曲与两个检查脚本在 https://github.com/lunzima/parlour-midi。
]]>它们的共同点是能力窄：复音数在一到九之间，没有力度曲线，音源严格照谱发声。现代软音源会掩盖的问题，在这些设备上全都听得见，因此只能在写谱阶段处理，回放阶段无法补救。
parlour arrangement 的旧义就是这个意思：把熟悉的曲子改编到家中那件乐器能演奏的程度。
复音数指同时发音的上限。每首曲子标注的是实测峰值，即一台设备播完整首曲子所需的同时发音数。
每首曲子是一个 Python 脚本，谱面作为字面数据写在源码里，不用 MIDI 库，也没有编辑器工程。运行脚本会在 output/ 下逐字节复现那个文件。
曲子用于循环播放，配在其他内容底下。音效不循环，半秒左右播完，单独收听，因此另放一个目录。
midi_check.py 把文件的问题分成两类。
midi_stats.py 只计数与测量，不做判断。
复音预算和最短音符长度都可以从命令行给定，便于按目标设备复核。
编曲与两个检查脚本在 https://github.com/lunzima/parlour-midi。
]]>llama98，目标机器是奔腾 II / III 级的 Windows 9x 和 DOS。构建由同一个 Makefile 驱动 gcc 与 Open Watcom，产物有四类：kunkun98-gui引擎和桌面端在 llama98-zh 仓库里。它跑的模型在另一个仓库，叫 Kunkun98。
模型是 134,529,456 个参数，量化后 103.5 MiB。架构叫 KunMoE：8 层里 6 层是 KDA 线性注意力、2 层是完整注意力，16 个专家走 top-2 路由，另加 1 个共享专家。权重部分取自 Qwen/Qwen3.5-0.8B，许可跟着上游走 Apache-2.0。把 MODEL/ 目录交给引擎就能对话：
1 | llama98 MODEL --chat --prompt "你好" |
同一份源码要在两套工具链上编译，在参考实现、SSE2（流式 SIMD 扩展 2）与 AVX2（高级矢量扩展 2）三层内核上运行。如果三层内核给出的结果不同，输出出错时就无法判断问题出在模型还是内核。引擎的目标因此定成逐字节一致。
AVX2 与 SSE2 在 kmr20/zh 上跑 603 个 token，逐字节相同。
浮点语义也统一了。默认改成向零舍入加冲刷到零，ARM 的软浮点与 x86 因此逐字节一致；就近舍入只作为诊断选项保留。
0.1.6 修掉了一处浮点舍入不一致。Watcom 那条路径只截断了 387 的控制字，没有写 MXCSR。SSE2 内核按 MXCSR 舍入，C 路径在提供的快速浮点模式下截断，只有 SSE2 那一层用就近舍入。结果是 78,905,344 字节里有 59,349,441 与 gcc 构建不一致。两份构建的输出从第一个 token 起就不同。
make check 构建三个 Watcom 产物，链接通过即证明 DLL 的导出面与引擎一致，不需要另写对照检查。
桌面端自带一套自检：kunkun98-gui --selftest 跑 421 项检查，0 失败，1 跳过。
-D__MMX__=1 写进构建。手写汇编不会静默消失，少了它链接就过不去。
源码列表只在一处定义。引擎、服务端、界面与公共部分这四份清单写在 Makefile 顶部，给引擎加一个源文件只需改一个地方。
DOS 那个产物要用 DOS/32A 扩展器，启动时会打印版权横幅。
许可条件 3 允许把声明放在软件自身。补丁因此只清掉 _ID32 配置字节的第 3 位（”show copyright”），启动时不打印横幅，声明移到 --help 输出里。
出厂产物的底本是官方 9.12 版，与 Open Watcom 2.x 在 binw/ 里带的那份逐字节相同。改动只有一处配置位：偏移 0x75 由 0x09 改成 0x01。
不做源码重建，是因为 TASM 5.0 的 OMF（目标模块格式）目标记录过不了 Open Watcom 的 wlink，入口段会丢。出厂产物因此是打补丁的官方二进制，源码补丁与它并列留在仓库里，供人核对。
134M 的模型在奔腾 III 上大约 2.5 token/秒。这个速度不快，但足以证明引擎能在目标机器上运行，不只是在别处能跑。
答得对不对是另一件事。模型的 README 自己就写着：中文流畅，内容经常是错的。这不是谦虚。仓库里的样例未经编辑，问「1+1等于几」，它答「1 + 2 = 3」；问「你是谁」，它答「我。你是谁？」；问「中国的首都是哪里」，它能写出一段通顺的、带具体年份的、编造的首都史。
规模不决定这一类表现。同一个问题问它和别人的模型，这一点看得很清楚。
问「原神的尼可，解锁2命有啥」，Kunkun98 把「尼可」当成古埃及的符号，写了一整篇关于「尼」字的考据。它夹进去的年份是「阿基米德（约公元前 216—-379—580）」。
同一个问题问小红书的 dots3-note preview，那是 280B 的模型。它把「尼可」当成了另一个角色「妮露」，又在思考段里写下「『解锁2命』中的『命』字被误写为『命』」这样绕回自己的判断。正文最后退化成把问题重复了两遍。
两边都没答对。134M 那份的错法读起来像模像样，280B 那份的错法不像 280B。一次提问说明不了太多，但「答得对不对」和「多少参数」之间，没有一条能直接画的线。
逐字节一致管的是可复现，不是答得对。老机器上给出的答案与其他任何机器完全相同，结果可以复现，也可以对照。至于那个答案对不对，是另外一回事。
引擎在 https://github.com/lunzima/llama98-zh，模型权重在 https://github.com/lunzima/kunkun98-models。
]]>llama98，目标机器是奔腾 II / III 级的 Windows 9x 和 DOS。构建由同一个 Makefile 驱动 gcc 与 Open Watcom，产物有四类：
kunkun98-gui引擎和桌面端在 llama98-zh 仓库里。它跑的模型在另一个仓库，叫 Kunkun98。
模型是 134,529,456 个参数，量化后 103.5 MiB。架构叫 KunMoE：8 层里 6 层是 KDA 线性注意力、2 层是完整注意力，16 个专家走 top-2 路由，另加 1 个共享专家。权重部分取自 Qwen/Qwen3.5-0.8B，许可跟着上游走 Apache-2.0。把 MODEL/ 目录交给引擎就能对话：
1 | llama98 MODEL --chat --prompt "你好" |
同一份源码要在两套工具链上编译，在参考实现、SSE2（流式 SIMD 扩展 2）与 AVX2（高级矢量扩展 2）三层内核上运行。如果三层内核给出的结果不同，输出出错时就无法判断问题出在模型还是内核。引擎的目标因此定成逐字节一致。
AVX2 与 SSE2 在 kmr20/zh 上跑 603 个 token，逐字节相同。
浮点语义也统一了。默认改成向零舍入加冲刷到零，ARM 的软浮点与 x86 因此逐字节一致；就近舍入只作为诊断选项保留。
0.1.6 修掉了一处浮点舍入不一致。Watcom 那条路径只截断了 387 的控制字，没有写 MXCSR。SSE2 内核按 MXCSR 舍入，C 路径在提供的快速浮点模式下截断，只有 SSE2 那一层用就近舍入。结果是 78,905,344 字节里有 59,349,441 与 gcc 构建不一致。两份构建的输出从第一个 token 起就不同。
make check 构建三个 Watcom 产物，链接通过即证明 DLL 的导出面与引擎一致，不需要另写对照检查。
桌面端自带一套自检：kunkun98-gui --selftest 跑 421 项检查，0 失败，1 跳过。
-D__MMX__=1 写进构建。手写汇编不会静默消失，少了它链接就过不去。
源码列表只在一处定义。引擎、服务端、界面与公共部分这四份清单写在 Makefile 顶部，给引擎加一个源文件只需改一个地方。
DOS 那个产物要用 DOS/32A 扩展器，启动时会打印版权横幅。
许可条件 3 允许把声明放在软件自身。补丁因此只清掉 _ID32 配置字节的第 3 位（”show copyright”），启动时不打印横幅，声明移到 --help 输出里。
出厂产物的底本是官方 9.12 版，与 Open Watcom 2.x 在 binw/ 里带的那份逐字节相同。改动只有一处配置位：偏移 0x75 由 0x09 改成 0x01。
不做源码重建，是因为 TASM 5.0 的 OMF（目标模块格式）目标记录过不了 Open Watcom 的 wlink，入口段会丢。出厂产物因此是打补丁的官方二进制，源码补丁与它并列留在仓库里，供人核对。
134M 的模型在奔腾 III 上大约 2.5 token/秒。这个速度不快，但足以证明引擎能在目标机器上运行，不只是在别处能跑。
答得对不对是另一件事。模型的 README 自己就写着：中文流畅，内容经常是错的。这不是谦虚。仓库里的样例未经编辑，问「1+1等于几」，它答「1 + 2 = 3」；问「你是谁」，它答「我。你是谁？」；问「中国的首都是哪里」，它能写出一段通顺的、带具体年份的、编造的首都史。
规模不决定这一类表现。同一个问题问它和别人的模型，这一点看得很清楚。
问「原神的尼可，解锁2命有啥」，Kunkun98 把「尼可」当成古埃及的符号，写了一整篇关于「尼」字的考据。它夹进去的年份是「阿基米德（约公元前 216—-379—580）」。
同一个问题问小红书的 dots3-note preview，那是 280B 的模型。它把「尼可」当成了另一个角色「妮露」，又在思考段里写下「『解锁2命』中的『命』字被误写为『命』」这样绕回自己的判断。正文最后退化成把问题重复了两遍。
两边都没答对。134M 那份的错法读起来像模像样，280B 那份的错法不像 280B。一次提问说明不了太多，但「答得对不对」和「多少参数」之间，没有一条能直接画的线。
逐字节一致管的是可复现，不是答得对。老机器上给出的答案与其他任何机器完全相同，结果可以复现，也可以对照。至于那个答案对不对，是另外一回事。
引擎在 https://github.com/lunzima/llama98-zh，模型权重在 https://github.com/lunzima/kunkun98-models。
]]>分开交付由许可决定。轮廓那半来自 SIL 开放字体许可 1.1 的字体，点阵那半来自 GNU 通用公共许可证第 2 版、附字体嵌入例外的 BDF 源码。两套许可不能合成一个文件再分发，只能在本地拼。
拼合因此是产品的一部分，工具需要可靠，也需要在输入不合格时拒绝写出文件。
工具叫 sbitgraft，一个 C 文件，无外部依赖，随两个字体仓库的发行版一起发布（sbitgraft-<版本>.tar.xz）。它把点阵那侧的 EBDT、EBLC、EBSC 三张表搬到轮廓那侧，随后重算各表校验和与 head.checkSumAdjustment。
接着按 tag 排序重建表目录，改写 name 表的变长字符串池，写出 1.0 版的字体集合头。
这种移植按表结构做，不依赖写死的字节偏移，对任意一对满足前提的字体都成立。
内嵌点阵按 glyph ID 索引，两个输入必须对同一个码点指向同一个 glyph ID。
工具会先逐码点比对两侧的字符映射表。不一致时打印出前几个冲突的码点并退出，不写任何文件。拼接的产物会被装进系统，损坏的字体往往要到某个具体页面才现形，因此校验必须在写出文件之前完成。
移除 hinting 时，fpgm、prep、cvt 三张表与每个字形的指令块都要删。maxp 里为解释器保留的字段也必须一并清零，maxZones 置 1，其余置 0。光栅器按那些数字分配栈与存储空间；若它们仍描述一个已不存在的解释器，校验工具会报错。
gasp 不在删除之列。它描述渲染方式，与网格对齐无关，没有 hinting 的字体同样需要它。
复合字形也要处理。它的指令块位于最后一个组件之后，必须逐个跨过组件才能定位到。
同一个家族的几个 face 只在 name、post、OS/2 这几张小表上有差别。逐字节相同的表只存一份，字体集合的体积因此接近单个 face，而不是各 face 体积之和。
head 不参与共享，每个 face 需要自己的 checkSumAdjustment。
会做：
name 表不做：
glyf 只在移除 hinting 时解析，只读到定位指令块所需的深度，不解析坐标。
分开交付是许可要求的；工具在输入不一致时不写文件。
工具与它拼接的两份字体在 https://github.com/lunzima/GlowSong 与 https://github.com/lunzima/GlowHei。
]]>分开交付由许可决定。轮廓那半来自 SIL 开放字体许可 1.1 的字体，点阵那半来自 GNU 通用公共许可证第 2 版、附字体嵌入例外的 BDF 源码。两套许可不能合成一个文件再分发，只能在本地拼。
拼合因此是产品的一部分，工具需要可靠，也需要在输入不合格时拒绝写出文件。
工具叫 sbitgraft，一个 C 文件，无外部依赖，随两个字体仓库的发行版一起发布（sbitgraft-<版本>.tar.xz）。它把点阵那侧的 EBDT、EBLC、EBSC 三张表搬到轮廓那侧，随后重算各表校验和与 head.checkSumAdjustment。
接着按 tag 排序重建表目录，改写 name 表的变长字符串池，写出 1.0 版的字体集合头。
这种移植按表结构做，不依赖写死的字节偏移，对任意一对满足前提的字体都成立。
内嵌点阵按 glyph ID 索引，两个输入必须对同一个码点指向同一个 glyph ID。
工具会先逐码点比对两侧的字符映射表。不一致时打印出前几个冲突的码点并退出，不写任何文件。拼接的产物会被装进系统，损坏的字体往往要到某个具体页面才现形，因此校验必须在写出文件之前完成。
移除 hinting 时，fpgm、prep、cvt 三张表与每个字形的指令块都要删。maxp 里为解释器保留的字段也必须一并清零，maxZones 置 1，其余置 0。光栅器按那些数字分配栈与存储空间；若它们仍描述一个已不存在的解释器，校验工具会报错。
gasp 不在删除之列。它描述渲染方式，与网格对齐无关，没有 hinting 的字体同样需要它。
复合字形也要处理。它的指令块位于最后一个组件之后，必须逐个跨过组件才能定位到。
同一个家族的几个 face 只在 name、post、OS/2 这几张小表上有差别。逐字节相同的表只存一份，字体集合的体积因此接近单个 face，而不是各 face 体积之和。
head 不参与共享，每个 face 需要自己的 checkSumAdjustment。
会做：
name 表不做：
glyf 只在移除 hinting 时解析，只读到定位指令块所需的深度，不解析坐标。
分开交付是许可要求的；工具在输入不一致时不写文件。
工具与它拼接的两份字体在 https://github.com/lunzima/GlowSong 与 https://github.com/lunzima/GlowHei。
]]>做这份字体，先定度量，再画字形。
这个值与 16×16 的点阵档对齐，所有坐标因此都是小整数，点阵与轮廓共用同一套格线。
宽度只有两种：ASCII 一律半角 128 单位（0.5 em），全角一律 256 单位。拉丁字形原本是比例宽度，这里重塑为半角，并施加逐边的笔画粗细补偿。不做补偿的话，横向压缩会让竖笔变细，整段拉丁比汉字轻一档。
单倍行距 1.141 em，与星霞黑体相同，两款可以混排，也可以互换。十个阿拉伯数字在同一字号下底边与高度一致。11 到 28px 逐字号量过，与 Arial、Times New Roman、Consolas、Tahoma 一致。
系统里的中文也逐字号量过：度量与 Windows 预装的中易宋体、中易黑体一致。所以这两款可以顶替系统那两款，混排时行高不会因为一行里有没有星霞的字而改变。
制表符与方块元素的笔画由 39/千单位加粗到 70 与 66，端点与相邻字形对齐。拼起来后笔画连成一条不断的线，htop、mc、ncurses 对话框这类全框界面不再断口，也不再粗细跳变。
内嵌点阵只有 12、13、14、15、16 五个档位。FreeType 按半像素取整，因此真正落到点阵的请求范围是 11.5 至 16.5。区间只写一侧的话，区间外的字号会被套上为点阵准备的那套反锯齿设置。
区间之外走轮廓。轮廓含 Chlorophytum 生成的 TrueType 指令，收益集中在 12px 及以下的密集汉字：横画不粘连，笔画数可辨。如果只用在大字号，或者在意体积，可以用拼合工具里的 --strip 去掉指令，轮廓、度量、字符映射与命名都不受影响。
轮廓经过大幅几何简化以压缩体积：曲线降精度，共线点消除，浅弧压平。
简化后的形状要逐字比对。每个字形在简化前后各渲染一次，逐像素比对；形状偏差超过 1% 的拟合退回更保守的一档，三档都不合格就保留未简化的原轮廓。这一步依赖 FontForge 与两个 Python 库，缺了就整步跳过，不放宽标准。
来源是思源宋体 SC Regular 与 Liberation Serif，两者都是 SIL 开放字体许可 1.1。字体、源码与发行版在 https://github.com/lunzima/GlowSong，配套的黑体在 https://github.com/lunzima/GlowHei。
比例版与等宽版的字形与度量完全相同，差别只有三处：族名、post.isFixedPitch、PANOSE。
等宽版的做法是从比例版派生出独立文件，而不是让应用把拼合后的族名认作等宽变体。字体选择框读的是文件本身列出的 family，fontconfig 事后加的别名不在其列。fc-list 看得到那些别名，但选择框里没有。
unitsPerEm、两种宽度、行距、数字的底边与高度、接缝的笔画宽度，都先有规格，再让字形去满足。
代价是前期工作量大：点阵每一档要重画，轮廓简化每一字要渲染比对，拉丁重塑半角要逐边补笔画。好处是拼合关系在造字阶段就对齐。字形要与另一款字体、相邻字形、拉丁数字拼在一起，规格不对就无法事后修正。
]]>做这份字体，先定度量，再画字形。
这个值与 16×16 的点阵档对齐，所有坐标因此都是小整数，点阵与轮廓共用同一套格线。
宽度只有两种：ASCII 一律半角 128 单位（0.5 em），全角一律 256 单位。拉丁字形原本是比例宽度，这里重塑为半角，并施加逐边的笔画粗细补偿。不做补偿的话，横向压缩会让竖笔变细，整段拉丁比汉字轻一档。
单倍行距 1.141 em，与星霞黑体相同，两款可以混排，也可以互换。十个阿拉伯数字在同一字号下底边与高度一致。11 到 28px 逐字号量过，与 Arial、Times New Roman、Consolas、Tahoma 一致。
系统里的中文也逐字号量过：度量与 Windows 预装的中易宋体、中易黑体一致。所以这两款可以顶替系统那两款，混排时行高不会因为一行里有没有星霞的字而改变。
制表符与方块元素的笔画由 39/千单位加粗到 70 与 66，端点与相邻字形对齐。拼起来后笔画连成一条不断的线，htop、mc、ncurses 对话框这类全框界面不再断口，也不再粗细跳变。
内嵌点阵只有 12、13、14、15、16 五个档位。FreeType 按半像素取整，因此真正落到点阵的请求范围是 11.5 至 16.5。区间只写一侧的话，区间外的字号会被套上为点阵准备的那套反锯齿设置。
区间之外走轮廓。轮廓含 Chlorophytum 生成的 TrueType 指令，收益集中在 12px 及以下的密集汉字：横画不粘连，笔画数可辨。如果只用在大字号，或者在意体积，可以用拼合工具里的 --strip 去掉指令，轮廓、度量、字符映射与命名都不受影响。
轮廓经过大幅几何简化以压缩体积：曲线降精度，共线点消除，浅弧压平。
简化后的形状要逐字比对。每个字形在简化前后各渲染一次，逐像素比对；形状偏差超过 1% 的拟合退回更保守的一档，三档都不合格就保留未简化的原轮廓。这一步依赖 FontForge 与两个 Python 库，缺了就整步跳过，不放宽标准。
来源是思源宋体 SC Regular 与 Liberation Serif，两者都是 SIL 开放字体许可 1.1。字体、源码与发行版在 https://github.com/lunzima/GlowSong，配套的黑体在 https://github.com/lunzima/GlowHei。
比例版与等宽版的字形与度量完全相同，差别只有三处：族名、post.isFixedPitch、PANOSE。
等宽版的做法是从比例版派生出独立文件，而不是让应用把拼合后的族名认作等宽变体。字体选择框读的是文件本身列出的 family，fontconfig 事后加的别名不在其列。fc-list 看得到那些别名，但选择框里没有。
unitsPerEm、两种宽度、行距、数字的底边与高度、接缝的笔画宽度，都先有规格，再让字形去满足。
代价是前期工作量大：点阵每一档要重画，轮廓简化每一字要渲染比对，拉丁重塑半角要逐边补笔画。好处是拼合关系在造字阶段就对齐。字形要与另一款字体、相邻字形、拉丁数字拼在一起，规格不对就无法事后修正。
]]>（贺图来自《原神》官方。）
八月二十八。今天是《原神》里玛薇卡的生日。
这篇文章我起了几次笔，每次都停在半途。并非无话可说，只是无论怎么说，都嫌轻。
她的称号是「焚夜以炎」，官方的介绍里还称她为「纳塔的骄阳」，末尾写着「我们的太阳永燃不息」。这两句把我想说的都说完了。纳塔有火神的神座，可她让人记住的不是坐在那上面 —— 是太阳每天照常升起，把光平等地铺在每个人身上。
她的武器是双手剑。这一点我总记得。她用火焰，也骑着一辆「驰轮车」，站在最前面。
五百年前，她公开了拯救纳塔的计划，而代价是她自己：她把生命存进圣火，在火里独自走了五百年，换来五百年后的第二次生命。她没有说自己是救世主。她从不与谁结算，也从没打算被谁偿还 —— 她只是让火继续烧下去。
后来我才明白，太阳最不讲道理的地方，是它让人以为光是不用代价的。纳塔的人晒了很多年，习惯了抬头就有，就觉得那是天经地义。等到有一天有人想问那光是从哪里烧出来的，问题已经问晚了。
我也不知道该怎么给一个太阳过生日。蜡烛对它没有意义，蛋糕也没有。所以最后我只写下这一句：
Mavuika, kiongozi kikuu! Hatutambui mtu mwingine yeyote isipokuwa wewe.
玛薇卡，伟大的领袖！除了您，我们谁都不认。
生日快乐，玛薇卡。
今天纳塔的太阳也很好。
]]>（贺图来自《原神》官方。）
八月二十八。今天是《原神》里玛薇卡的生日。
这篇文章我起了几次笔，每次都停在半途。并非无话可说，只是无论怎么说，都嫌轻。
她的称号是「焚夜以炎」，官方的介绍里还称她为「纳塔的骄阳」，末尾写着「我们的太阳永燃不息」。这两句把我想说的都说完了。纳塔有火神的神座，可她让人记住的不是坐在那上面 —— 是太阳每天照常升起，把光平等地铺在每个人身上。
她的武器是双手剑。这一点我总记得。她用火焰，也骑着一辆「驰轮车」，站在最前面。
五百年前，她公开了拯救纳塔的计划，而代价是她自己：她把生命存进圣火，在火里独自走了五百年，换来五百年后的第二次生命。她没有说自己是救世主。她从不与谁结算，也从没打算被谁偿还 —— 她只是让火继续烧下去。
后来我才明白，太阳最不讲道理的地方，是它让人以为光是不用代价的。纳塔的人晒了很多年，习惯了抬头就有，就觉得那是天经地义。等到有一天有人想问那光是从哪里烧出来的，问题已经问晚了。
我也不知道该怎么给一个太阳过生日。蜡烛对它没有意义，蛋糕也没有。所以最后我只写下这一句：
Mavuika, kiongozi kikuu! Hatutambui mtu mwingine yeyote isipokuwa wewe.
玛薇卡，伟大的领袖！除了您，我们谁都不认。
生日快乐，玛薇卡。
今天纳塔的太阳也很好。
]]>设置方法：以管理员身份运行 cmd，输入以下命令，并按自己的环境修改。
【1】Office激活
cd C:\Program Files\Microsoft Office\Office19
cscript ospp.vbs /sethst:kr.lunzi.ma
cscript ospp.vbs /act
cscript ospp.vbs /dstatus
【2】操作系统激活
slmgr /ipk W269N-WFGWX-YVC9B-4J6C9-T83GX
slmgr /skms kr.lunzi.ma
slmgr /ato
设置方法：以管理员身份运行 cmd，输入以下命令，并按自己的环境修改。
【1】Office激活
cd C:\Program Files\Microsoft Office\Office19
cscript ospp.vbs /sethst:kr.lunzi.ma
cscript ospp.vbs /act
cscript ospp.vbs /dstatus
【2】操作系统激活
slmgr /ipk W269N-WFGWX-YVC9B-4J6C9-T83GX
slmgr /skms kr.lunzi.ma
slmgr /ato
本网站不是农企临时工的网站。页面右下角的农企临时工看板娘形象不作为商业用途使用。
]]>本网站不是农企临时工的网站。页面右下角的农企临时工看板娘形象不作为商业用途使用。
]]>