关于emacs字体显示的问题(或者说KDE的字体渲染)

标题是这样,不过其实问题本身不在于emacs,我想大概在于KDE的字体渲染(抗锯齿),想了想决定分享出来和大家一起考虑。
我在我自己的配置中没有用任何第三方包来管理字体的显示(你可以看到一个形如(use-package fontset ...)的片段),也没有在字体本身上做什么特别的优化,所以问题大概的确是在于KDE的显示问题:我在配置GNU APL的major mode时在:hook里使用了一个匿名函数,让emacs在此时使用BQN386字体,它在所有的:height下都表现得雾蒙蒙。尽管这的确是这款字体本身的字形所引发的,但显示上绝对也和KDE的渲染有关。
我想到的是,存在一种量化的指标来衡量字体的渲染效果与其字形上的某种特征的关系么?如果存在,或者其两者间具有一定的相关性,emacs有能力让用户自己来改变这种状态么?如果不存在,有一种最佳实践可以做到尽可能地消去锯齿么?

我很久没有接触桌面美化了,不知道现在的KDE用户都在使用什么方案。

linux字体渲染就两个东西吧,subpixel和inting,这两个东西emacs应该没有对应的内置api。

1 个赞

最悲伤的一集,开了抗锯齿之后fc-cache -fv了一下,现在所有firefox上的字体都fallback到了一个不知道名字的点阵字体上了 :joy:似乎是之前捣鼓时清掉了firefox的什么cache,现在它不知道该怎么办了

fc-match 查看当前用的字体, fontconfig 自定义字体显示

我的设定把NotoSans映射到了APL385上,中文则是Unifont,我觉得大概是.fonts或者类似的文件的优先级出错了,现在fontconfig也不好用,让我试试直接删掉它再生成可不可以