为什么日语字体突然无法正确显示？情况非常复杂，这个群曾经工作过，但在一次与新代码发布同时发生的平台升级后就崩溃了。可能是代码的问题，但该代码在 Mac 或 Ubuntu Desktop 开发操作系统上运行良好。
环境：
- Ubuntu 14.04 Server Headless 升级（在 Cloud Foundry 上：无 sudo 权限）
- 使用 Electron Chromium win.webContents.printToPDF 生成 PDF
- Electron 版本 1.6.2（尝试过较新的 3.0.13）
容器中没有 Root 权限使得这个问题/解决方案变得困难。无法控制或洞察底层操作系统的修补进一步加剧了不确定性。
我们分叉了 Pivotal CF 节点构建包，并在构建包的编译阶段实现了类似于此代码片段的内容（示例：https://github.com/heroku/heroku-buildpack-xvfb-google-chrome/blob/master/bin/compile) 使用应用程序中的 Aptfile 指定以本地用户身份安装哪些 apt-get 安装包。
这个疯狂的包运行得很好，直到上个月，日语字符无法正确显示。一个可能至关重要的变化是托管人员将容器的基础操作系统从 Ubuntu 14.04 升级
$uname -a
魔法升级仙女之前：
Linux e4e7267c 4.4.0-75-generic #96~14.04.1-Ubuntu SMP Thu Apr 20 11:06:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
升级后出现邪恶小精灵：
Linux c3fa6d0b 4.15.0-38-generic #41~16.04.1-Ubuntu SMP Wed Oct 10 20:16:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
奇怪的是，16.04 之后的版本显示该版本仍然是 Trusty：$lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty
从 14.04 到 16.04 升级库的依赖关系是否发生了变化？Xvfb 是否改变了它处理字体路径和查找的方式（底层是 X.org）？
字体安装到本地用户帐户如下：$ ls -ltr app/.apt/usr/share/fonts/X11/
total 84
drwxr-xr-x 2 vcap vcap 4096 Jan 2 14:19 util
drwxr-xr-x 2 vcap vcap 4096 Jan 2 14:19 Type1
drwxr-xr-x 2 vcap vcap 20480 Jan 2 14:19 misc
-rw-r--r-- 1 vcap vcap 2 Jan 2 14:19 fonts.dir
drwxr-xr-x 3 vcap vcap 4096 Jan 2 14:19 encodings
drwxr-xr-x 2 vcap vcap 4096 Jan 2 14:19 cyrillic
drwxr-xr-x 2 vcap vcap 16384 Jan 2 14:19 75dpi
drwxr-xr-x 2 vcap vcap 16384 Jan 2 14:19 100dpi
为了实现这一目标，部分黑客技术涉及使用 sed 替换 Xvfb 中的硬编码路径引用，以使用本地用户的目录路径。
也许该功能在 Xvfb 的新升级版本中发生了变化。
如果您对进一步的故障排除、黑客技巧或潜在原因/解决方案有任何想法，我们将不胜感激。
