java - 如何安装 Java 9 openjdk 应用程序所需的最小字体集

Question

我有一台 blackbox linux 机器，它只有一种字体 /usr/lib/fonts/ipag.ttf但它似乎没有正确安装和自定义 openjdk 9 安装

openjdk 安装时没有任何字体，但我尝试创建一个字体目录并将此字体复制到其中，但没有效果。

当我运行我的非 gui 应用程序时，它需要字体才能使用 jakarta-poi 创建 excel 电子表格，但它失败了:

Caused by: java.lang.NullPointerException
    at java.desktop/sun.awt.FontConfiguration.getVersion(Unknown Source)
    at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(Unknown Source)
    at java.desktop/sun.awt.FontConfiguration.init(Unknown Source)
    at java.desktop/sun.awt.X11FontManager.createFontConfiguration(Unknown Source)
    at java.desktop/sun.font.SunFontManager$2.run(Unknown Source)
    at java.base/java.security.AccessController.doPrivileged(Native Method)
    at java.desktop/sun.font.SunFontManager.<init>(Unknown Source)
    at java.desktop/sun.awt.FcFontManager.<init>(Unknown Source)
    at java.desktop/sun.awt.X11FontManager.<init>(Unknown Source)

然后我试着运行

fc-cache -rv /usr/lib/fonts

这报告字体已安装(尽管 fc-list 未返回任何内容)

现在我的应用程序更进一步了，但仍然失败，报告

Caused by: java.lang.NullPointerException
    at java.desktop/sun.awt.FcFontManager.getDefaultPlatformFont(Unknown Source)
    at java.desktop/sun.font.SunFontManager$2.run(Unknown Source)
    at java.base/java.security.AccessController.doPrivileged(Native Method)
    at java.desktop/sun.font.SunFontManager.<init>(Unknown Source)
    at java.desktop/sun.awt.FcFontManager.<init>(Unknown Source)
    at java.desktop/sun.awt.X11FontManager.<init>(Unknown Source)

那么我该如何解决这个问题，我不清楚我的 Java 应用程序运行所需的最小字体集是什么。我不清楚我是否只需要提供字体或 fonts.properties 文件，或者该文件仅由 Oracle jres 而不是 OpenJdk 使用

我在使用 OpenJdk1.8 时遇到了同样的问题，但是从内存中简单地创建一个字体文件夹并将字体放入其中似乎可行，但现在这个 openjdk 9 版本不起作用。

我可以将字体复制到机器上，但我无法运行安装命令将字体直接安装到机器上。

更新

然后我复制了 Oracle jre 提供的 Lucida 字体并放入 jre/libs/font 并在该文件夹上运行 fc-cache -rv 现在它可以工作了，为什么 ipag.ttf 字体不够？

为什么我必须运行 fc-cache 而不是 java 只是通过在字体文件夹中找到它们来获取字体。

Answer 1

最近的 openjdk 和 java 版本使用 fontconfig，它可以在广泛的语言环境中选择合适的字体(或字体替换)(例如，当没有系统字体单独具有足够的覆盖范围时，从多种字体构建文本)。它比只涵盖一组有限的编码和语言环境的旧系统更完整和准确，只能做出简单的决定并需要在 fonts.properties 文件中手动声明字体替换顺序。基本上，旧系统无法扩展到世界上的语言环境数量和当今 unicode 的复杂性

但是要计算出正确的选择，fontconfig 需要首先对字体进行分析和索引。这就是 fc-cache 的意义所在。 Fontconfig 不能只按需读取字体文件，例如，Google Noto 字体家族仅重量为千兆字节，它需要预先计算一个索引，以便在有一段文本要呈现时帮助快速选择正确的文件。 Lucida 是一种具有玩具(按照当前标准)unicode 覆盖率的传统字体。

由于 fontconfig 的全部意义在于避免在最后一分钟读取大量复杂字体文件的巨大计算损失，因为它们至少存在于安装系统的人中，它至少依赖于生成其索引(缓存)有问题的时刻。例如，当您安装字体包时，RHEL/Centos 等 Linux 发行版会自动执行此操作。

我不记得你是否可以配置 fontconfig 来监视它的字体目录并在它们发生变化时自动生成新的缓存。这可能不是一个好主意，索引复杂的 opentype unicode 字体需要大量计算，并且众所周知，人们会在日志中移动文件，同时按顺序排列字体目录。

fontconfig 希望找到要索引的字体的实际目录取决于您的系统配置。

为什么 ipag.ttf 不够用？这取决于文件的内容。一个 ttf 文件可以包含数以万计的字形或仅包含一个对编写文本无用的虚荣符号。