search

AOSC-Dev / liblol

libLoL (LoongArch on LoongArch): Old-world ABI compatibility runtime
28 stars 1 forks source link

WPS 等程序中存在字体显示问题 #4

Closed MingcongBai closed 7 months ago

MingcongBai commented 8 months ago

根据测试和用户报告反馈，目前发现 WPS 和 LoongBlock 两个程序部分界面存在中文字体无法正常显示的情况

WPS 文字 > 从模板新建：

图片

LoongBlock 青少年编程平台：

图片

初步调查显示（通过查询 ls -la /proc/$PID/map_files/ | grep font），AOSC OS 预装的 NotoSansCJK-VF.ttf.ttc 会导致问题，如果删除此文件则可解决问题；目前判断应该是 libLoL 运行时中或 WPS 等应用自带的 libfreetype/libfontconfig 导致的问题，如无简单解法（尤其是需要改动软件自带文件），则可以考虑：

  1. 改变 AOSC OS 主系统中字体的打包方法：选用兼容性更好的独立 TTF/TTC 文件
  2. 在 libLoL 自带一份字体套件（但存储代价比较大，暂不考虑）
shankerwangmiao commented 8 months ago

交叉实验证实，将该字体文件放入旧世界 loongnix 系统内，也会导致 WPS 呈同样现象。

https://github.com/notofonts/noto-cjk/issues/217 指出，Variable OTC 和 HarfBuzz<3.3.0 不兼容。但是将 lol 的 HarfBuzz 升级至 6.0.0 后，故障仍然存在。

将 lol 的 fontconfig、freetype、pango 一并升级后，故障依然存在。

通过 map_files 查看该界面对应的 promecefpluginhost 进程，发现其的确载入了新版本的 HarfBuzz 库。

另查：在 wps 打包的 libQt5GuiKso.so 中，可以找到与 libharfbuzz 中存在的大量相似的字符串，提示该库已经静态连接了 libharfbuzz。目前较大的疑惑是：WPS 主界面（Qt 编写）字体渲染没有问题，反而是插件中心（Chromium 改）出了问题，且插件中心进程的确又载入了系统提供的 libharfbuzz。

又查：在旧世界系统中放入该字体文件后，再不替换任何运行库的情况下，其它诸如 gedit 等应用工作正常，即使手工删除了旧世界系统中所有 Noto 的字体，仅放入该字体文件，在 gedit 中强行设置为该字体显示，文字仍然渲染正常。

MingcongBai commented 7 months ago

经查，该问题是 Noto Sans VF（可变字体）与这些程序内建的 libQt/libfreetype 等库不兼容导致的；为兼容性考量，AOSC OS 已在一月字体更新中换用非 VF 格式的相关字体，至此问题得到解决