我遇到了以下令人恼火的问题，数周以来我一直在尝试解决，但至今无果。
*警告：问题过长——简而言之：*本质上，我需要的是一种系统范围的方法来准确定义将使用哪些字体来显示给定的 unicode 代码点。理想情况下，这个决定将通过引用 unicode 代码块来做出，并提供一种方法来为缺失的代码点提供后备方案，此外，还可以为单个代码点定义覆盖。
我至今还没有找到解决办法，网上很多描述对于 ubuntu 10.04 来说似乎已经过时了。
有用的答案确实包括对当前 ubuntu 字体渲染如何工作的解释或指示，以及您可能配置的内容。
*详细说明：*
我经常使用来自所谓“星界”的 unicode 字符，即代码点超出 unicode 最初的 16 位的字符。现在有很多情况（浏览器地址栏、终端、文本编辑器）无法像在文字处理器或 html/css 文件中那样配置字体，在这些文件中，您可以明确定义要显示的每个字符的字体。
相反，在每个这样的应用程序中，图像的出现取决于系统上安装的字体、应用程序范围的设置、可能的字体系统配置，以及您的好运或坏运。
为了处理中文/日文/韩文 (cjk) 字符，我安装了 Sun-ExtA.Ttf、Sun-ExtB.Ttf 和 BabelStoneHan.Ttf，以及许多其他字体，包括默认的 ubuntu 字体。此外，我还 (在 wine 下)巴别地图并完成我所有的编辑Komodo 编辑 6.1。
Komodo 配置为使用 DejaVu Sans Mono，我发现使用起来非常愉快。通过系统范围的字形替换（我相信），我得到了很多正确的 cjk 代码点图像。但是，我不完全确定这些图像确实源自上述字体。您会看到，cjk 块包含超过 70000 个代码点，有些有细微的差别，有些有可忽略不计的变体，有些则是完全复制的。这是一个令人惊讶的棘手问题。基本上，只有当您绝对确定给定代码点的外观时，您才能成功地从事这一领域的工作，而我发现最忠实的渲染包含在上述字体中。
不幸的是，ubuntu 似乎搞乱了不少代码点。例如，
u-cjk/5f50 彐
u-cjk-rad1/2f39 ⼹
u-cjk-rad2/2e95 ⺕
在所有应用程序中（包括没有正确 css 的 Firefox 和 Komodo），这三个代码点在我的计算机上看起来完全相同。但是，如果你在类似这样的源代码中查找这些字符http://www.longwiki.net/%E5%BD%90（彐，⼹，⺕)，根据我的经验，它为所讨论的字符精选了非常出色的 gif，但这三个代码点之间存在细微的差别。
我不太高兴 unicode 选择定义这么多几乎相同的代码点，但几十年来，cjk 编码一直被认为是一个相当困难的问题。现在我确实安装了字体（这里是 Sun-ExtA.Ttf），可以以预期的外观呈现这三个代码点，但我的感觉是这些字体永远没有机会呈现，因为 ubuntu 或其他人在某些时候会介入，声明所有这些代码点都应该合并为一个。或者可能是 ubuntu 认为这些代码点的正确字体进行了合并。让我告诉你为什么这不太可能是正确和期望的行为：从上面的列表中你可以看到代码点位于三个不同的 unicode 块中，即
CJK UNIFIED IDEOGRAPHS
KANGXI RADICALS
CJK RADICALS SUPPLEMENT
分别。unicode 联盟对所谓的“部首”形成了一种相当奇怪的观点，这意味着他们把它们当作“符号”（用于词典中的部分符号），而不是“字符”（用于编写文本），我认为这是纯粹的胡说八道。这一政策促使 unicode 不止一次地包含“馬”这样的字符，因为
u-cjk/99ac 馬
u-cjk-rad1/2fba ⾺
在我看来，这显然是无理代码点重复的情况，unicode 的既定政策是这些点显示相同，但要区别对待。现在，虽然已知并承认存在无意字符/字形重复的情况（一些委员会被淹没在无数的代码点中，并多次承认一个字符——其他代码集也存在这个问题），但在这种情况下，这种情况极不可能发生。这两个部首块只有几百个代码点长，而补充的部首块是在引入主要“康熙”部首块（甚至命名也很古怪）之后才添加的，例如区分字形的唯一目的。因此，假设这种双重字符不太可能是由错误引入的（任何一年级的中文学生都可以检查这些简短列表的正确性——这就是你在学习中文时花费大量时间整理和记住所有那些相似字符的原因），我们必须得出结论，至少两个代码点的外观差异完全是 unicode 的本意，因此，我的计算机试图说服我它们应该看起来相同是错误的。
我注意到的另一个故障是，一些间歇性的代码点肯定是使用与大多数其他字体不同的字体显示的；例如，下面第一组中的三个代码点由某种无衬线字体（可能是来自 Ume Gothic 或 Wen Quan Yi 系列）呈现，而第二个代码点则以歌曲风格呈现：
u-cjk/534b 卋
u-cjk/5359 卙
u-cjk/535b 卛
u-cjk/534c 卌
u-cjk/534f 协
u-cjk/535a 博
这种行为可以在 gedit 和 komodo edit 中观察到，所以我可以非常确定它发生在操作系统级别，而不是在应用程序内。
观察所讨论的代码点，它们都是直接相邻的代码点，因此我猜测默认的歌曲风格字体缺少一些代码点，而 ubuntu 认为无衬线字体包含这些点的最佳替代方案——但结果错了，因为毕竟已安装的 Sun-ExtA.ttf 确实完整覆盖了此 unicode 块的歌曲风格字形（也就是说，我从未见过真正有效的字形替换系统）。
上面我提到了 BabelMap，它是进行字符编码工作的一个非常有用的工具。BabelMap 的一个突出方面是，可以以非常易于管理的方式配置字形表，以便为每个 Unicode 块使用特定的字体。实际上，我希望对一些边界情况进行更细粒度的控制，但这似乎是这个时代所能达到的最佳效果了。