`ccmp` 查找时错误地将重复的假名组合成达克腾字形 (例如, いい → い゛)

顿! 我喜欢用"枫花",所以我想把日本卡纳修好

□ 说明

在CN建筑中,连续打入两个相同的kana(如: ,ああ,かか),导致第二个字符由一些渲染器中发音/半发音(dakuten/handakuten)的glyph组成,所以いい就成了"`い". 这对正常的日文文字输入来说显然是意想不到的.

□ 环境

• 字体: Maple Mono NF CN(v7.9),测试所有重量
• 受影响的渲染器:Zed(编辑缓冲器)、Windows终端、Wim在Windows终端
• 未受影响:VS代码编辑器,Zed集成终端,和HarfBuzz塑造(见下文)

□ 根源(通过字体分析确定)

" ccmp " 的特征是提到 " LigatureSubst " 检索(我所检查的文件中的检索索引5),其中载有23份表格图:

3044 Uni3044 - > Uni3044 3099 (合并计算)
uni3042 uni3042 - > uni30423099 (+++++++++++++++++++++++++++++)
uni304B uni304B - > uni304B309A (++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.(23个共计,平原+卡塔克纳)

由 " uni30443099 " 所构成的目标文字(例如 " uni30443099 " )在字体中存在,但** 无法通过任何cmap编码点** ——它们只能通过这种 " ccmp " 替代生产。 因此任何重复的同型卡纳都会被默默地合并为达库腾/汉达库腾形式.

□ 有趣的细节: 渲染器依赖

该替代在HarfBuz singing下进行不起火(重复的kana作为两个独立的glyphs),但does起火在Zed的编辑缓冲器和Windows终端. 这解释了为何同一字体在某些上下文中看起来精细而在其他上下文中被打碎,甚至在同一个应用中也是如此. 由于它生活在"ccmp"(强制功能)中,用户不能通过编辑器/terminal字体版面设置来禁用.

□ 影响

任何使用重复的kana来写普通日文的用户(极常见的——如QQ,QQ,QQ,QQ)都会在受影响的渲染器中看到被腐蚀的输出,没有通过特性切换来进行用户侧面的工作.

□ 建议修正

从CN建筑的 " ccmp " 搜索中取出或关闭重复的-kana-dakuten/handakuten绘图,除非有特定的预期用途。 如果为了某种目的需要这些成分,它们不应被默认文本流中两个完全相同的kana所触发.

□再现.

1. 安装 Maple Mono NF CN。
2. 在Zed编辑器缓冲器或Windows终端中,类型为QQ.
3. 观察其为 QQ,而不是两个单独的 QQ.