葡萄酒中的字体识别？
Font recognition in wine?
我目前正在使用 wine 在 linux 下为 运行 开发一个应用程序，它需要使用 CJK 字体显示（仅显示，无输入）文本。让我觉得有趣的是 Microsoft 字体以某种方式相互链接的方式，例如：
如果我使用 winetricks 只安装 Tahoma，并且 运行 它，它会显示无法显示的字符框，然后当我安装所需的字体时，例如：MingLiu，即使我只选择了 Tahoma，文本也会正确呈现作为默认字体。
我认为的结论是，当一个人试图渲染它无法渲染的字符时，Microsoft 字体会以某种方式相互链接，就像这样的逻辑：
"try using Tahoma, if it can't render some characters, render them using other font that can (e.g: MingLiu), while still render the latin characters using Tahoma"。奇怪的是，当我使用非 Microsoft 的其他 CJK 字体时不会发生这种情况，例如：Hanazono (http://fonts.jp/hanazono/)，即使 Hanazono 可以渲染一些需要显示的字符。如果我选择 Tahoma 或任何其他字体，它将永远无法呈现 CJK 字符，即使 Hanazono 存在于当前的 wineprefix 中。
我用来重现此 "phenomenon" 的步骤：
- 从clean wineprefix开始（我用winetricks删除所有wineprefix）
- 从 winetricks 安装 Tahoma
- 运行 应用
- 注意无法渲染的乱码或方框字符
- 关闭应用程序，将需要的字体（例如：MingLiu）复制到wineprefix目录下的windows/Fonts目录
- 重新运行 应用程序
- 注意完美呈现的角色
- 重复步骤 1-4
- 关闭应用程序，将应该能够正确呈现文本的替代字体（例如：Hanazono）复制到 wineprefix 目录中的 windows/Fonts 目录
- 重新运行 应用程序
- 注意仍然是乱码或方框字符
我真的不知道从哪里开始寻找解决方法，无论是某种 wine-feat，还是一些特定于字体的琐事。最简单的解决方案是嵌入 Microsoft 字体，但由于它会引发法律问题，所以我更喜欢使用我可以自由使用的第三方字体。任何信息都会有帮助，谢谢。
今天谷歌搜索，然后我找到了这篇文章：https://msdn.microsoft.com/en-us/library/ms901083.aspx
似乎 "font linking"（用于定义我寻找的特征的术语）通过定义一些注册表值来工作，并在 regedit 上进行试验后，在 HKLM 中添加名为 "DejaVu Sans" 的新 MultiString 值-Software-Microsoft-WindowsNT-FontLink-SystemLink，值为：
HanaMinA.ttf, HanaMinA
HanaMinB.ttf, HanaMinB
我可以 link DejaVu Sans 和 Hanazono 字体渲染 CJK 字符 DejaVu Sans 无法渲染。
需要注意的是，这个实验只适用于 wine，因为在 Windows 中，某种字体 linking 可以工作 "automagically" 而无需手动定义注册表，这可能会导致误以为相同的文本渲染在 运行 在 wine 下看起来是一样的。
如果上面的方法不起作用，试试这个。
wine regedit
导航至：
HKEY_CURRENT_USER\Software\Wine\Fonts
看看你是否有一个名为的子项：Replacements
如果是 - 您可以安全地删除该子项 仅。
我目前正在使用 wine 在 linux 下为 运行 开发一个应用程序，它需要使用 CJK 字体显示（仅显示，无输入）文本。让我觉得有趣的是 Microsoft 字体以某种方式相互链接的方式，例如： 如果我使用 winetricks 只安装 Tahoma，并且 运行 它，它会显示无法显示的字符框，然后当我安装所需的字体时，例如：MingLiu，即使我只选择了 Tahoma，文本也会正确呈现作为默认字体。
我认为的结论是，当一个人试图渲染它无法渲染的字符时，Microsoft 字体会以某种方式相互链接，就像这样的逻辑： "try using Tahoma, if it can't render some characters, render them using other font that can (e.g: MingLiu), while still render the latin characters using Tahoma"。奇怪的是，当我使用非 Microsoft 的其他 CJK 字体时不会发生这种情况，例如：Hanazono (http://fonts.jp/hanazono/)，即使 Hanazono 可以渲染一些需要显示的字符。如果我选择 Tahoma 或任何其他字体，它将永远无法呈现 CJK 字符，即使 Hanazono 存在于当前的 wineprefix 中。
我用来重现此 "phenomenon" 的步骤：
- 从clean wineprefix开始（我用winetricks删除所有wineprefix）
- 从 winetricks 安装 Tahoma
- 运行 应用
- 注意无法渲染的乱码或方框字符
- 关闭应用程序，将需要的字体（例如：MingLiu）复制到wineprefix目录下的windows/Fonts目录
- 重新运行 应用程序
- 注意完美呈现的角色
- 重复步骤 1-4
- 关闭应用程序，将应该能够正确呈现文本的替代字体（例如：Hanazono）复制到 wineprefix 目录中的 windows/Fonts 目录
- 重新运行 应用程序
- 注意仍然是乱码或方框字符
我真的不知道从哪里开始寻找解决方法，无论是某种 wine-feat，还是一些特定于字体的琐事。最简单的解决方案是嵌入 Microsoft 字体，但由于它会引发法律问题，所以我更喜欢使用我可以自由使用的第三方字体。任何信息都会有帮助，谢谢。
今天谷歌搜索，然后我找到了这篇文章：https://msdn.microsoft.com/en-us/library/ms901083.aspx
似乎 "font linking"（用于定义我寻找的特征的术语）通过定义一些注册表值来工作，并在 regedit 上进行试验后，在 HKLM 中添加名为 "DejaVu Sans" 的新 MultiString 值-Software-Microsoft-WindowsNT-FontLink-SystemLink，值为：
HanaMinA.ttf, HanaMinA
HanaMinB.ttf, HanaMinB
我可以 link DejaVu Sans 和 Hanazono 字体渲染 CJK 字符 DejaVu Sans 无法渲染。
需要注意的是，这个实验只适用于 wine，因为在 Windows 中，某种字体 linking 可以工作 "automagically" 而无需手动定义注册表，这可能会导致误以为相同的文本渲染在 运行 在 wine 下看起来是一样的。
如果上面的方法不起作用，试试这个。
wine regedit
导航至：
HKEY_CURRENT_USER\Software\Wine\Fonts
看看你是否有一个名为的子项：Replacements
如果是 - 您可以安全地删除该子项 仅。