如何安装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列表不返回任何内容）

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

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应用程序工作所需的最小字体集是什么。我不清楚我只需要提供字体或一个字体。属性文件，或者该文件仅由Oracle JRE而不是OpenJdk使用

我对OpenJdk1也有同样的问题。然而，从内存中简单地创建一个字体文件夹并将字体放入其中似乎是可行的，但这在这个openjdk 9版本中现在不起作用。

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

使现代化

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

为什么我必须运行fc缓存？java只是通过在字体文件夹中查找字体来提取字体。

Answer 1

最近的openjdk和java版本使用fontconfig，它可以在广泛的区域设置中选择合适的字体（或字体替换）（例如，当没有系统字体具有足够的覆盖面时，从几种字体中构建文本）。它比旧系统更加完整和准确，旧系统只涵盖有限的编码和区域设置，只能做出简单的决定，并需要在fonts.properties文件中手动声明字体替换顺序。基本上，旧系统无法扩展到世界上的地区数量和今天Unicode的复杂性

但要计算正确的选择，fontconfig需要首先分析字体并编制索引。这就是fc缓存的意义所在。Fontconfig不能只按需读取字体文件，例如，Google Noto字体系列仅重千兆字节，它需要预先计算索引，以帮助在出现要渲染的文本时快速选择正确的文件。Lucida是一种旧式字体，具有toy（按当前标准）unicode覆盖范围。

由于fontconfig的全部目的是避免在最后一刻仅仅因为存在大量复杂字体文件而读取大量复杂字体文件所带来的巨大计算损失，因此它依赖于安装系统的人在最短的时间内生成其索引（缓存）。例如，在安装字体包时，RHEL/Centos等Linux发行版会自动执行此操作。

我不记得你是否可以配置fontconfig来监视它的字体目录，并在它们改变时自动生成新的缓存。这可能不是一个好主意，索引复杂的opentype Unicode字体是非常计算密集型的，人们已经知道在日志中移动文件，同时将他们的字体目录排序。

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

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