Fonts 葡萄酒中的字体识别？

我目前正在开发一个在linux和wine下运行的应用程序，它需要使用CJK字体显示（只显示，不输入）文本。让我感到有趣的是，Microsoft字体以某种方式相互链接，例如： 如果我使用WineTracks仅安装Tahoma并运行它，它会显示无法显示的字符框，然后当我安装所需字体（例如：MingLiu）时，即使我只选择Tahoma作为默认字体，也会正确呈现文本

我想得出的结论是，当一个人试图渲染它无法渲染的字符时，Microsoft字体以某种方式相互链接，某种程度上类似于以下逻辑： “尝试使用Tahoma，如果它不能呈现某些字符，请使用其他可以呈现的字体（例如：MingLiu）呈现它们，同时仍然使用Tahoma呈现拉丁字符”。奇怪的是，当我使用其他不是微软的CJK字体时，这种情况并没有发生，例如：Hanazono（），尽管Hanazono可以渲染一些需要显示的字符。如果我选择Tahoma或任何其他字体，它将永远无法呈现CJK字符，即使当前wineprefix中存在Hanazono

我用来重现这种“现象”的步骤：

从干净的wineprefix开始（我使用WineTracks删除所有wineprefix）

从WineTracks安装Tahoma

运行应用程序

请注意无法呈现的乱码或方框字符

关闭应用程序，将所需字体（例如：MingLiu）复制到wineprefix目录中的windows/Fonts目录

重新运行应用程序

请注意完美渲染的角色

重复步骤1-4

关闭应用程序，将能够正确呈现文本的替代字体（例如：Hanazono）复制到wineprefix目录中的windows/Fonts目录

重新运行应用程序

请注意仍然是乱码的方框或字符

---

我真的不知道从哪里开始寻找解决方法，无论是某种葡萄酒技艺，还是一些字体特定的琐事。最简单的解决方案是嵌入Microsoft字体，但由于这会引起法律问题，我更喜欢使用我可以自由使用的第三方字体。任何信息都会有帮助，谢谢。

今天在谷歌上搜索，然后我发现了这篇文章：

“字体链接”（用于定义我所寻找的特征的术语）的工作原理似乎是定义一些注册表值，在对regedit进行实验后，在HKLM软件Microsoft WindowsNT FontLink SystemLink中添加名为“DejaVu Sans”的新多字符串值，值为：

HanaMinA.ttf, HanaMinA
HanaMinB.ttf, HanaMinB

我可以将DejaVu SAN与Hanazono字体链接，以呈现DejaVu SAN无法呈现的CJK字符

---

应该注意的是，这个实验只适用于wine，因为在Windows中，字体链接以某种方式“自动”工作，而不需要手动定义注册表，这可能导致错误地认为在wine下运行时相同的文本呈现看起来是相同的。

如果上述方法不起作用，请尝试此方法

wine regedit

导航到：

HKEY\U当前用户\软件\葡萄酒\字体

查看是否有名为：

Replacements

如果是-您可以安全地仅删除该子项