search

AOSC-Dev / liblol

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

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

Closed MingcongBai closed 10 months ago

MingcongBai commented 10 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 10 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 10 months ago

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