如何安装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 cant java只需通过在fonts文件夹中找到它们来获取字体.

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 文件可以包含数以万计的字形或仅包含一个对编写文本无用的虚荣符号。