debian中输入偏旁部首，候选词会显示方块

[驿窗project]

我在网上搜索下载msyh.ttf和msyh.otf字体文件，安装到Ubuntu Linux里，依然是5和6显示为乱码，但其中一个形状有变化。
但是这个网上下载的msyh.ttf文件大小只有14.3M，文件的修改时间是2006年9月25日；
同样在网上下载的MSYH.otf文件大小只有15.5M，文件的修改时间是2019年3月29日；
而我Win10复制过来的msyh.ttc文件大小有18.7M，文件的修改时间是2019年12月7日。也许多出来的这3~4M数据，就是新增的3万汉字？

我的理解是，这多出来的3~4M数据，应该不是增加字符，而是新增的hint数据，用来美化现有字符显示的。

可以验证一下，就是用字体管理软件打开这几个字体文件，然后对比字符的实际数量就行了。
(gnome桌面的字体管理包叫font-manager)

[驿窗project]

在我的 Debian 12 系统里，从下面的偏旁部首里，用 ibus-libpinyin 随意（randomly）的选择输入完全没有问题，候选词栏也不会出现方块：
丨 亅 丿 乛 一 乙 乚 丶
八 勹 匕 冫 卜 厂 刀 刂 儿 二 匚 阝 丷 几 卩 冂 力 冖 凵 人 亻 入 十 厶 亠 匸 讠 廴 又
艹 屮 彳 巛 川 辶 寸 大 飞 干 工 弓 廾 广 己 彐 彑 巾 口 马 门 宀 女 犭 山 彡 尸 饣 士 扌 氵 纟 巳 土 囗 兀 夕 小 忄 幺 弋 尢 夂 子
贝 比 灬 长 车 歹 斗 厄 方 风 父 戈 卝 户 火 旡 见 斤 耂 毛 木 肀 牛 牜 爿 片 攴 攵 气 欠 犬 日 氏 礻 手 殳 水 瓦 尣 王 韦 文 毋 心 牙 爻 曰 月 爫 支 止 爪
白 癶 歺 甘 瓜 禾 钅 立 龙 矛 皿 母 目 疒 鸟 皮 生 石 矢 示 罒 田 玄 囗 疋 业 衤 用 玉
耒 艸 臣 虫 而 耳 缶 艮 虍 臼 米 齐 肉 色 舌 覀 页 先 行 血 羊 聿 至 舟 衣 竹 自 羽 糸 糹
貝 采 镸 車 辰 赤 辵 豆 谷 見 角 克 里 卤 麦 身 豕 辛 言 邑 酉 豸 走 足
青 靑 雨 齿 長 非 阜 金 釒 隶 門 靣 飠 鱼 隹
風 革 骨 鬼 韭 面 首 韋 香 頁 音
髟 鬯 鬥 高 鬲 馬
黄 鹵 鹿 麻 麥 鳥 魚
鼎 黑 黽 黍 黹
鼓 鼠
鼻 齊
齒 龍 龠

这些字在我这里也没问题；
并且，我以前使用其它输入法也没有方块的问题，但现在使用单手笔顺输入法时，会明显看到候选词显示方块；所以，你这里没看到方块，应该是你的输入法有可能不支持输入那些可能方块的字形。

要重现问题的话，可能需要安装单手笔顺输入法来测试~

到目前为止，我比较倾向于astolia的解释，就是单手笔顺使用的码表，使用了“不那么规范”的区位(或者不常用的区位)，这导致那些只使用规范区位(常用区位)的字体无法正常显示它们。

yq-ysy在windows下使用完全没问题，所以按这个方向猜测的话，不能依赖字体来解决这个问题，可能修改编码方案是方向(windows是不是在utf-8以外做了啥)~

[yq-ysy]

在我的 Debian 12 系统里，从下面的偏旁部首里，用 ibus-libpinyin 随意（randomly）的选择输入完全没有问题，候选词栏也不会出现方块：
丨 亅 丿 乛 一 乙 乚 丶
齒 龍 龠

这些字在我这里也没问题；
并且，我以前使用其它输入法也没有方块的问题，但现在使用单手笔顺输入法时，会明显看到候选词显示方块；所以，你这里没看到方块，应该是你的输入法有可能不支持输入那些可能方块的字形。
要重现问题的话，可能需要安装单手笔顺输入法来测试~

到目前为止，我比较倾向于astolia的解释，就是单手笔顺使用的码表，使用了“不那么规范”的区位(或者不常用的区位)，这导致那些只使用规范区位(常用区位)的字体无法正常显示它们。
yq-ysy在windows下使用完全没问题，所以按这个方向猜测的话，不能依赖字体来解决这个问题，可能修改编码方案是方向(windows是不是在utf-8以外做了啥)~

哈哈，我在Win10下破案啦！！！
进入windows目录的Fonts目录，然后按文件大小排列，排在前面的当然大多是中文字体。
然后我看到在Win10下使用Rime“单手笔顺输入法”时，候选字即有黑体，也有宋体，
于是就重点挑选了几个黑体字和宋体字来测试——我一看见有个 SimSun-ExtB，就知道肯定是它没错了。
由于我很怀疑windows的“记事本”和Word一样，会在后台调用其他汉字来补充显示，
所以我干脆使用3D动画软件 Blender 测试 Win10 中文字体，测试过程和结果如下所示：
你也可以在浏览器里复制以下文字（现在应该显示为方框），然后放到文本编辑器里，修改字体，测试看看能显示吗？

----第一行，已经录入“单手笔顺输入法”编码的汉字约3万个：----
调用 msyh.ttc 即 微软雅黑 仅可见前4个，
调用 Deng.ttf 即 等高 仅可见前5个，
调用 STSONG.TTF 华文宋体 或 STZHONGS.TTF 华文中宋 可见前6个，
调用 simsunb.ttf 即 SimSun-ExtB常规 仅可见后4个。
能乙乛乚𠃊𠃋𠃌𠃍

----第二行，尚未录入“单手笔顺输入法”编码的汉字超4万个：----
调用 simsunb.ttf 即 SimSun-ExtB常规 可见全部。
𪛃𪛄𪛅𪛆𪛇𪛈𪛉𪛊𪛋𪛌𪛍𪛎𪛏𪛐𪛑𪛒𪛓𪛔𪛕𪛖

但是，我把这几个字体复制到 Ubuntu Linux 下，在 Ibus 的设置里指定，却没有起作用，依然是第5和第6有乱码。
去年一整年我都没见过乱码，今年才有的。
所以，我认为问题应该出在：Ubuntu 系统升级后，改动了字体的优先级，让某个不规范的英文字体抢先占用了第5和第6位。
而你的 Debain Linux 也是一样的道理。与我的“单手笔顺输入法编码”无关，我的编码严格遵守GB国标，没问题。
另：注意看windows的Fonts目录里面的中文字体“设计公司”那一栏，也是国内的公司哦，他们应该也是严格遵守GB国标来制作中文字体的。

我把 win10 的 simsunb.ttf 文件安装到 Ubuntu Linux 里之后，在Linux里的FireFox网页和LibreOffice的Writer里也能显示生僻字了。
但输入法候选字栏原本的第5位也依然是乱码（因为我输入过，Rime自动调高了字频，所以跑到上面去了）。
又把 win10 的 STSONG.TTF 华文宋体 安装到 Ubuntu Linux 里之后，那两个字在FireFox网页也是乱码，但在Writer里显示正常。
在输入法候选字栏原本的第5位也依然是乱码。
因此，我更确认问题应该出在：Ubuntu 系统升级后，改动了字体的优先级，让某个不规范的英文字体在FireFox和Ibus里抢先占用了第5和第6位。
而Writer能分辨出这是亚洲语言字体，所以Writer就能选择正确的字体来显示这两个字。

[驿窗project]

转楼

[yq-ysy]

由于Unicode编码包含大量日韩使用的、与汉字字型笔画完全相同的文字（即同一个字重复出现两次），极易造成混淆，故不以此为标准。

我能不能这么理解，因为onehand没有使用Unicode编码，所以导致linux系统出现候选词方块？
我不太清楚怎么验证Linux使用什么标准，但默认情况下，Linux是不是应该使用unicode标准？

windows是不是优先不使用unicode标准？

唉，你都没有仔细看 10楼 我发的截图：

Unicode编码是乱七八糟、不管什么字体都包含进来的，既包括有日韩字符集，也包括有GB18030字符集。
所以你看图里，我收录的每个汉字，编码都是必然属于GB18030编码、同时也属于Unicode编码的。
GB18030编码也包含有日文的片假名、平假名，也有韩文的圈圈杠杠文，也包含有某些笔画差异很明显的“日韩汉字”，但是——
——那些日韩使用的、与汉字字型笔画完全相同的文字，肯定不会出现在我们中国人的GB18030编码里！
它们也许会出现在日韩的专用字体里，同时也属于Unicode编码，这很正常，Unicode编码就是大杂烩一锅炖。

微软那么专业的操作系统公司，做的Windows是分语言区域的，日韩就用日韩的专用字体，中国就用中国的专用字体。
不能贪省事乱用Unicode编码就想蒙混过关的，会被几个国家的用户骂死。

[驿窗project]

我尝试看截图，发现截图特别虚，看不清楚，不知道是不是我这边的问题～

[yq-ysy]

所以，需要simsunb.ttf这个字体？
这个方案有点难以接受，因为这会导致商业使用存在障碍~

不用。你的思维有点乱……
你不用安装simsunb.ttf这个字体，因为我现在的“单手笔顺输入法”还没录入全部7万汉字，安装了也没用。
现在的“单手笔顺输入法”仅有近3万汉字，使用 Ubuntu Linux 未升级的安装包来安装系统，是能全部显示这3万汉字的。
你在 Debain Linux 里有方框和乱码，应该是字体的优先级调用问题，或者是字体不全的问题。

解决方法有二：
一是把 Ubuntu 使用的字体全部都安装到 Debain 里。
二是修改 Debain 的字体的优先级，改成与未升级的 Ubuntu 字体优先级一模一样。
我觉得，你干脆还是直接换用 Ubuntu 系统更方便，不要用 Debain 了，省心省事。

[yq-ysy]

我尝试看截图，发现截图特别虚，看不清楚，不知道是不是我这边的问题～

哦，之前复制粘贴的是“缩略图”的地址，现在已经改正，用高清原图的地址了，可以点击放大看了。

[驿窗project]

转楼

[yq-ysy]

我的目的并不是我要使用onehand输入法，而是把这个输入法介绍给其它debian小白用户可以傻瓜式使用。但即使上面几个方案可以解决问题，也意味着用户要多走几步，而这几步对于小白用户来说并不容易。

结果可能是，要么放弃onehand输入法，要么放弃debian，或者，多走几步。无论哪个，好像都是坏消息，因为这不够简单，或者说，本来有更简单的方案，但我们没有提供。这是从开发者角度来看的，毕竟，onehand的开发者可以帮助小白用户开箱即用。

这个我也没办法，因为我不是程序员，我写不出一个输入法的应用程序，也就无法在程序里对字体进行优化设定。
目前“单手笔顺输入法”是依靠在Rime上的，而在Linux中，Rime又是依靠在IBus上的，所以，我也感到很无奈。

继续努力挣钱吧，按现在的价格算，没有十万二十万都请不到程序员来写输入法的应用程序。
花十年攒够二十万？哈，到那时，也许已经变成需要一百万才能聘请程序员了……悲哀。

[驿窗project]

我的目的并不是我要使用onehand输入法，而是把这个输入法介绍给其它debian小白用户可以傻瓜式使用。但即使上面几个方案可以解决问题，也意味着用户要多走几步，而这几步对于小白用户来说并不容易。

结果可能是，要么放弃onehand输入法，要么放弃debian，或者，多走几步。无论哪个，好像都是坏消息，因为这不够简单，或者说，本来有更简单的方案，但我们没有提供。这是从开发者角度来看的，毕竟，onehand的开发者可以帮助小白用户开箱即用。

我仍然在继续写《Linux入门指南》，以我有限的水平来写这本书，不容易，不容易的地方是我需要亲身不断去试错，找出那些让小白用户烦恼的地方，标注为“此路不通”；然后去继续寻找和尝试其它可用的代替方案。原则可以理解为KISS。

但这个方块的问题，除非我推自己的发行版 ，否则无法按KISS目标来解决。而改用ibus-rime或fcitx，则明显更接近KISS目标。

这也是我为什么一直在“方块”上纠结的原因。

你提到的无奈，我其实给的方案是提供两个版本的码表，一个小一个大，这样是可以解决问题的。

linux要开箱即用，这是我期望的方向~

[astolia]

前前后后写了那么些底层的技术原理，就没人认真去看的，以后再也不干这种吃力不讨好的事了。一堆奇谈怪论也懒得去一一去驳斥了，自己爱信什么信什么吧

[Ping-Wu]

(post deleted by author)

[驿窗project]

我写了一大堆不能应用fongconfig的理由，两次都是一提交就没了~

也许是这会儿这个帖子比较紧张？我换个时间再发~

[yq-ysy]

如果说中间两个字的话，可不是什么生僻字的问题，可以算是你做的码表的问题。one_hand.text.dict.yaml里面大量字符的unicode编码是在私人使用区里面。私人使用区这东西，就是unicode规范不做规定，字体可以随意映射到任意字形上。所以只有安装了对应的字体才能显示正确的字形。楼主遇到的情况是，他系统上没有任何字体提供了对应的字形；而你图上的情况是，虽然系统中有字体提供了对应的字形，但却不是原本的字体，所以显示的字形不一样。
经测试需要用windows上的宋体才能显示出正确的字形。

我在 Win10 的测试（18楼）印证了 astolia 所说的：
虽然系统中有字体提供了对应的字形，但却不是原本的字体，所以显示的字形不一样。经测试需要用windows上的宋体才能显示出正确的字形。

我说的是用fc-match列出的某个字体名称与字体匹配列表，比如

代码： 全选

fc-match -s 宋体

就会列出当你指定字体名称为宋体时，实际候选的字体列表。
你的这个 more /etc/fonts/conf.d/65-nonlatin.conf 只是fontconfig的配置文件之一，会影响到部分名称的最终的候选列表，但不是候选列表本身

这有啥好分析的，不就是你指定的字体名称对应的候选字体中缺少那些字形么。以前又不是没教过你怎么看候选字体列表及匹配优先级

我不知道应该如何修改“某个字体名称与字体匹配列表”。fc-match 命令只能查看，不能修改？
fc-match --help
用法：fc-match [-savbVh] [-f <输出格式>] [--sort] [--all] [--verbose] [--brief] [--format=<输出格式>] [--version] [--help] [匹配模式] {元素…}
列出符合 [匹配模式] 的最佳字体
-s, --sort 显示已排序的匹配列表
-a, --all 显示未修剪而已排序的匹配列表
-v, --verbose 详尽显示整个字体匹配模式
-b, --brief 简略显示整个字体匹配模式
-f, --format=<输出格式> 使用指定的输出格式
-V, --version 显示 Fontconfig 版本并退出
-h, --help 显示该帮助信息并退出

前前后后写了那么些底层的技术原理，就没人认真去看的，以后再也不干这种吃力不讨好的事了。一堆奇谈怪论也懒得去一一去驳斥了，自己爱信什么信什么吧

也许是因为太“底层"了，跨度太大，对于像我这样对字体的调用机制一窍不通的，也许还要花很多时间去学习这方面的知识，才能弄明白。
而又希望能尽快帮助”驿窗“解决问题，就只好靠自已实验、摸索，然后想当然地自己乱解释、乱猜测了。
抱歉让高手灰心了。

我和”驿窗“都属于”程序应用者“，能用这个软件完成这件事，总结自己的经验再写个教程，分享给网友就OK了。对于更”底层“的东西，确实是一无所知。
所以在遇到问题的时候，最原始的希望是——”修改某处设置，就能解决问题”——于是上网搜教程。
如果不行，就更进一步——”复制什么文件、运行什么命令，就能解决问题”——于是来论坛问步骤。
如果还不行，需要编程改代码、需要编译、或者需要先学习更深层次的东西——这就太难了。

前前后后写了那么些底层的技术原理，就没人认真去看的，以后再也不干这种吃力不讨好的事了。一堆奇谈怪论也懒得去一一去驳斥了，自己爱信什么信什么吧

（表情）

上大学时，我的《机械制图》课程轻轻松松就能拿98分，但有些同学不喜欢这课程，很努力很痛苦才勉强及格。
反过来，在《模拟电路》和《数字电路》这类课程上，有些同学轻轻松松就能拿高分，轮到是我考试不及格。
为了准备开学前的补考，在春节期间大年三十、大年初一仍在看书复习（当时真的是一边看书一边想哭，太痛苦了），最后才61分通过。
我到现在依然觉得，我的那次补考本来也是不及格的，这61分是任课老师可怜我，才多给的。

我说这些的意思是，人各有所长，数学天才不会画画，歌唱家不会弹钢琴，写程序的不会写小说，都很正常。
在教别人某个知识的时候，对方隔行如隔山，在某些方面脑子转不过弯，是很常见的。
我在职业学校教Blender，也遇到类似的事情，有很喜欢这门课的学生，但他在三维图形方面的想像力、接受能力比较差，讲了几次都不明白。
所以这时候，就需要耐心和方法，换个角度讲解，分解成更细的步骤一步一步讲解，这样才能让他一步一步弄明白。
当然，老师的耐心也是有限度的，对于实在不开窍的这学生，受不了了，于是放弃，这也可以理解。——急性子遇到慢郎中，不凑巧而已。