上下跳动的文字

我觉得我自从手搓几个low-level的文本绘制之后这个问题其实已经变成专家了。问题本身其实还是很有趣的,这里特别总结一下。

不少人可能都注意到了 Linux 下面有时候会有一种奇怪的现象,就是你输入文字的时候,一旦输入了汉字,汉字可能会把整行文字的位置降低。删除掉汉字的时候,则又会恢复到原本。这是为什么呢?

其实道理是很简单的,就是你这一行文字混合了两种不同的字体。为什么明明没有单独配置但是却使用了不同的字体?因为系统默认使用的英文字体本身,可能并不包含汉字。因此当需要显示汉字(或者其他任何不存在于这个字体的字符)时,就只能回落(fallback)到另外的字体上。你也许注意到了,即使两种字体配置为同一个大小(point),但是实际显示在屏幕上的大小可能是不同的。当两个字体同时在一行文本中使用的时候,为了将他们对齐,则需要使用一个标准将两个字体的文本对齐。这个标准就是基线(baseline)

A diagram showing the line terms used in typography, with the baseline highlighted.
图片来自 Wikipedia

这里还有两个重要的线 ascent 和 descent。ascent 就是从 baseline 到字体的最高点,descent 就是 baseline 到字体的最低点。可以假想一下,当另一个字体混入的时候,如果它的 ascent 高于原本字体的 ascent,自然就需要将文本整体“下推”。

gedit

通过辅助线,我们可以明显观察到 DejaVu 和中文字体组合之后可以出现明显的下沉现象。

对于编辑器来说,只有两种方式,一种允许每行的高度不同,从而适配文字本身的大小, 另一种则是每行高度相同,但带来的副作用可能是会对 fallback 到的较高的字体砍头去尾。

这里有一个展示了 katepart 曾经长时间存在的文字渲染问题,当字体可能下推文本过多时,超过了原本的行高,则不得不砍掉了一些。右侧是经过我修复之后的 katepart。

这里所谓的修复是什么呢?其实非常的简单,就是把“下推”的文字拉回原本只有单个字体的基线位置。简单的来说,就是进行这样的运算:在 y 轴上偏移一个这样的数值:(渲染文本的整体 ascent – 字体本身的 ascent)。

这样运算之后,那些并非 fallback 的字符将不会被「下推」,而保持在原始的位置。fallback 到其他字体的字符则会对应的上拉一些位置。你可能会问了,这样似乎并没有解决字体被砍头的问题啊?确实,但字体设计的时候,一般会在顶部留有余地不会紧密排列,经过这样调整之后,反而会让大部分即使是 fallback 的字符也完整显示在行内,同时还会避免跳动的问题。

同时,如果你多次使用文本绘制 API 来绘制多条文本,这样也可以保证他们自动会对齐在一起。否则则可能出现即使逻辑上是一行,但是因为文本不同而上下参差不齐的问题。

Posted in Linux | Tagged , | Leave a comment

How to use a missing keyboard layout in Fcitx 5

When Fcitx read the layout information, it read from xkeyboard-config, mostly like to be /usr/share/X11/xkb/rules/evdev.xml on your system. But unfortunately, there might be missing data in this file and you should report the bug to bugs.freedesktop.org for missing data.

But what if you want to use the layout right now without waiting for the bugfix for xkeyboard-config?

Here’s an easy way to do it at user level.

For example, if you use setxkbmap -layout br -variant abnt2 to setup your keyboard input method, but you find this entry is not currently in evdev.xml files, then you can do:

1. Create a configuration for input method
Pleasse notice, the file name matters, it should be named by keyboard-[layout]-[variant].conf
The file name for this layout should be ~/.local/share/fcitx5/inputmethod/keyboard-br-abnt2.conf

[InputMethod]
Name=br-abnt2
Icon=input-keyboard
LangCode=pt_BR
Addon=keyboard
Configurable=True
Label=br

The “Name=” section in the file doesn’t really matter, you can put anything meaningful to you. LangCode= and Label= also doesn’t really matter.

2. Restart fcitx 5 to make it reload the data.

3. Open config tool to add it to the list.

4. Move it to the first place in the list, and you will get a popup that ask you: whether you want to fix the config to make the system layout configuration matches the first input method. You may click yes to set it. Because evdev.xml does not have the corresponding entry, you’ll not be able configure the system layout the regular way.

Then you should be able to use the layout just like using the setxkbmap command, enjoy!

Posted in fcitx development | Tagged , , | 1 Comment

Linux 的 HiDPI 配置问题

其实这个问题对我来说从来也不是个问题,因为我已经基本深入理解了这个问题的本质……然而似乎有不少人对于怎么配置,为什么这么配置,为什么又出了问题一知半解,因为最近在 Twitter 上回复一些比较复杂的内容,特此整理记录一下。

在过去,电脑的屏幕一般都是 96 DPI,DPI 的含义是每英寸点数(像素点),具体计算的方法也非常简单,用像素的个数除以屏幕的长宽即可。随着技术发展(显示器和处理器),电脑逐渐可以支持更高的 DPI 用于显示。抛开具体发展不提,但是这里引入了一个问题,你程序并不支持在这样的屏幕上正常显示。通常来说的问题就是界面特别小。

为什么?

因为程序过去从来也不需要考虑这个问题,都是按照像素来进行的设计,例如显示一个 100 x 100 的窗口,在 96 DPI 上大小正常,但是 DPI 翻倍的话,就只有原来的 1/4 大。人的眼睛在乎的是它现实中有多大(像素 / DPI = 长度),而不是有多少像素点。为了让程序能够正常显示,同时又不需要修改太多代码,大家也是努力想了很多办法。

1、设置字体大小。

界面框架大小不提,字看不清那是最难受的,因此只调整字体大小这样的设置,成为了大部分人解决问题的第一步。但是,在 X 上,这个设置是全局的,因此也就不能针对不同的屏幕,来设置一个统一的 DPI。一个屏幕大一个屏幕小也可以说是常态了,不少人就选择设置一个居中的值来自己适应。毕竟人是活的,程序是死的,改变不了世界那就只好自己适应世界。

2、程序来支持内部缩放。

这里,当然也就是 Qt / Gtk 这样的大框架才有精力和能力去支持这种功能。这个功能在程序不需要进行额外修改,或者只进行少量修改的前提下,直接在内部添加坐标的转换功能,乘以一个倍数,变相将程序放大。这样,在高分辨率的前提下,就可以用正常的大小显示界面。

3、设置分辨率来进行缩放

也许有人说,显示器不都可以配置分辨率么?你3200×1800的屏幕,我强行设置 1600×900 不就完全正常大小了么?这样说当然是没有问题,但是相对的你也就没有利用上这个屏幕的资源,原本你可以在更高的像素点上进行更好的反锯齿。相当于说,你把大图片缩小再放大,你得到的能是原始图片的效果么?必然是有数据损失的。当然,还是那句话,人是活的,程序是死的。一句 I don’t care 什么问题都能解决。

上面说的分辨率缩放只是在配置当中其中的一个方向。相反,还有故意把 1600×900 伪装成 3200×1800 这种操作,这是为什么呢?

这是因为,尽管在 2 中你可以靠 Toolkit 来放大程序的界面,但是如果你同时有两个不一样的屏幕,那这可就倒了大霉了。一个屏幕 96 DPI 一个屏幕 289 DPI,那你的程序是选哪一个 DPI 来显示呢?

关于这点,其实甚至还没有到「选哪个」的问题,支持根据屏幕动态切换 DPI 的 Toolkit 在 Linux 上只有 Qt 这一家。Gtk 根本就不支持动态在运行时根据屏幕切换 DPI。那你既想要显示“锐利”,又想要大小正常,那就只有一个办法了。把这个 96 DPI 的屏幕也变相变成 HiDPI 的。尽管你没有 HiDPI 的屏幕,但是你可以通过软件「装作」你有这么一个屏幕。

xrandr --output eDP-1 --scale 2x2 --mode 1920x1080 --pos 0x0 --output DP-1-0 --mode 2560x1440 --pos 3840x0

上面这条命令,就是把 eDP-1 在软件层面变成 3840×2160 的屏幕,放在左边,尽管它原生只有 1920×1080。这样有两个 DPI 相近的屏幕,你自然就可以对按照 2 对程序设置统一的缩放倍率了。

4、将他们组合在一起

先来说说 X 到底是怎么回事。对 X 来说,它不知道窗口里面什么 HiDPI 不 HiDPI,你给我什么,我就显示什么。所有坐标在 X 层面都是原生的。也就是说,它没法把不支持 HiDPI 的程序放大,例如一些 Java 程序或者 Xlib 程序。那怎么办?如果你非要一切程序都正常大小,那就只能走暴殄天物的方案 3 ,把分辨率人工降下来。

还是再重复一次,「人是活的,代码是死的」。你当然可以选择「那些不支持 HiDPI 的程序都是辣鸡,我不用了!」。为了享受「锐利」,你选择了只用 Gtk / Qt 的程序,其他程序如果能用调整程序内部字体凑合就凑合一下,凑合不了干脆不用,反正 Gtk / Qt 的选择那么多。

那么在你选择这条路的时候,首先就来了解一下 Gtk 和 Qt 设定上的不同。Gtk 的 scale factor 是影响字体大小的,而 Qt 的是不影响字体大小的。

通过下图,你可以很容易对比理解 Qt 和字体 DPI 组合的行为。

https://pbs.twimg.com/media/EvcWJYPVIAEo0x_?format=jpg&name=orig

然后再来对比一下 Gtk 的行为。

图像

也就是说,如果你想 Qt 和 Gtk 同时达到两倍缩放,并且大小相当,需要设置:

1、Xft DPI  192
2、QT_SCREEN_SCALE_FACTORS=2
3、GDK_SCALE=2 GDK_DPI_SCALE=0.5

具体数值你可以根据你的屏幕自行修改。当然,这些数值具体的设置方式可以通过环境变量,又或者可以通过桌面环境的设置,但不管通过哪种手段,本质其实是一样的。

在这个设置的基础上,又可以分别分成两个路线,使用 3 的方法伪装低 DPI 的屏幕,又或者你连 Gtk 也一起放弃,采用 Qt 可以支持不同屏动态切换 DPI 的设置。

QT_SCREEN_SCALE_FACTORS="eDP-1=1;DP-1-0=2"

例如这样设置的话,就可以在 eDP-1 用 1 倍缩放,DP-1-0 用两倍缩放。尽管 Xft DPI 还是只能一个值,但是 Qt 会自动帮你绑定到某个屏幕,另一个屏幕还是采取包括字体大小在内的完全缩放,把窗口在不同屏幕移动的时候也会自动调整程序的大小。当然为什么只有 Qt 实现了这个我猜想主要是因为 Windows 上只有这一种方案可以总是保持原生状态渲染,就顺带着也支持了 Linux 。

如果说到 Wayland(目前已有的实现),本质上是一样类似的,但是参数实际上就没有这么多花活可以弄。Wayland 对于窗口可以有一个窗口本身的 scale 是多少的属性,当然,得是原生 Wayland 窗口,X wayland 的窗口 scale 会自动当成是 1。然后这个窗口会在不同的屏幕上,根据屏幕的 scale 进行匹配缩放。这也就是为什么 Wayland 可以支持所谓的「分数」缩放(非整数百分比,例如 150%)。其实 X 如果你把 xrandr 的 scale 改成带小数的倍数也是可以的。

其实 Qt 在 X 下,也是可以支持非整数的 scaleFactor。但是这里有一个问题。浮点数的计算是有精度损失的,所以如果你原生进行内部坐标非整数的运算,实际上更有可能出问题,在哪里界面上缺掉一像素也是常见的事,相比整数倍数运算之后再缩放来说的方案,问题会少一些。但是希望大家还没有忘记 Wayland 下也还有X wayland 需要显示。根据之前说的情况 X Wayland 和 X 并没有什么差别,只是 3 中描述的操作现在交给 wayland compositor 进行了。GNOME 默认的行为是不缩放 X,可以通过 gsettings 启用一个实验性功能来让 X 被「放大」。KDE 是默认采用设置的倍数放大。相对来说,反而和 X11 相比更加不「自由」,并不能分开指定 Wayland 和 X 的缩放倍率。

毕竟,对有些人来说,显示锐利本身比大小更重要。左侧是原生 Wayland,右侧是 X wayland。尽管大小一致,在 150% 缩放的情况下 X 的程序自然是模糊了(从 100% 放大到 150 %)。而 Wayland 这个则是从 200% 缩小到 150%(当然,也许用 300 % 绘制再缩小 150 % 效果可能更好?但具体来说现在系统实现就是这样的)

https://pbs.twimg.com/media/EvcdZv1VIAQ4lkM?format=jpg&name=orig

整个 HiDPI 问题就是那么一个问题,怎么把原本针对小屏幕设计的窗口放到高分辨率上显示,和 X 还是 Wayland 有什么相关么?没有,只是在不同平台你有相对不同的变量可以操纵。有没有完美的解决方案?当然也是没有。你偏要把一个 100×100 的窗口当成 200×200 显示,窗口不支持缩放当然只能模糊。窗口支持缩放却又不支持动态切换,混合分辨率的在低分辨率上那就只能浪费资源来缩放,这本来就是两难的问题。真正完美的纯动态切换现在也就只有 X11 + Qt,但大部分人也不是靠纯 Qt 程序不是?非要概括的话,就是有钱能解决大部分问题,有钱就买俩 HiDPI 屏幕,有钱就硬件强力,浪费资源缩放也无所谓。

Posted in Linux | Tagged , , | Leave a comment

Fcitx 5 开发(三)如何调试输入法,先有鸡还是先有蛋

调试输入法,和写别的程序其实没有本质的区别,常见的办法也就是 GDB 和输出日志。但它特别的地方主要在于,你用来调试输入的程序也是输入法的客户端之一,在调试输入法的时候,如果不进行一些特别的操作,将会导致你调试用的终端 Freeze(把按键发送给了输入法,却因为程序 GDB 暂停无法获得响应导致 Freeze),也就是标题所说的先有鸡还是先有蛋的问题。

当然,要解决这个问题其实也简单,就是让你的终端不用输入法就行了。这里有几个点需要注意,常见桌面环境的终端一般是单实例,你即使启动一个新的窗口也是同一个进程,并不是重新启动一个进程。所以一般我个人会选择使用另外的终端程序。这是从终端程序禁止输入法方面来说。反过来,也可以通过命令行参数禁用 Fcitx 的前端。来阻止 Fcitx 和对应类型的程序进行通信。

先说说怎么启动一个无法使用输入法的终端。如果是 XIM 的终端,例如 xterm,alacritty,就直接用 XMODIFIERS=@im=none xterm 这样的方式启动,启动之后,在终端里面直接启动新的 fcitx 的话,就需要注意要在终端里面重新恢复 XMODIFIERS 的值为一般的值。因为根据 XMODIFIERS 的处理机制,Fcitx 会根据它启动时的 XMODIFIERS 设置对应的值。如果不进行设置的话,当前的这个终端自然也反而会可以和 Fcitx 通信了。如果是 Gtk 程序,可以设置 GTK_IM_MODULE=gtk-im-context-simple ,如果是 Qt 5程序,可以设置为 QT_IM_MODULE=compose 。

如果想要从 Fcitx 这边禁用输入法,那就需要利用 –disable 命令行参数。我常用的一般就是 fcitx5 --disable dbusfrontend,ibusfrontend。你也可以根据你具体的需要来设置禁用对应的 Frontend。

当然,这个并不是总是特别好用的。因为这里牵扯到第二个问题,就是程序的焦点问题。在你切换到终端的时候,你用来测试输入的程序就失去了焦点,会导致程序直接进入重置状态,很有可能无法达到原本想要调试的状态。这里就可以采取第二种方法,启动一个新的 X server,从而避免焦点抢占的问题。常用的一般就是 Xephyr。

可以用如下的命令来设置启动这样的一个环境

Xephyr :1 &
DISPLAY=:1 openbox & #启动一个窗口管理器
DISPLAY=:1 xterm & #启动一个调试用程序用于测试
DISPLAY=:1 gdb --args fcitx --disable dbusfrontend,ibusfrontend # 启用一个禁用 dbus 的 fcitx

这里需要注意的是,dbusfrontend 并不会因为显示服务器的隔离而无法进行输入,所以例如你要在 konsole 上进行调试,如果不禁用 dbusfrontend 的话,console 还是会收到按键。

所以如果你想要调试一个使用 dbusfrontend 的程序,就最好还用上前文所述的办法,在主显示服务器启动一个无法使用输入法的终端来进行调试。

Xephyr 不会因为它自身焦点改变而修改 Xephyr 里面运行的程序的焦点,就可以很方便的在 Xephyr 和外部终端之间来回切换调试一连串的输入行为了。

之后,你只需要在 Xephyr 里面进行键盘操作,在触发对应 gdb 断点之后,用鼠标切换到外部的终端继续进行调试即可。调试完成之后也可以用鼠标切换回到 Xephyr 里面再继续模拟另一些用户的操作。

调试来说,就还有传统的输出 Log 的方式。简单的来说用 FCITX_INFO() << item << to << output; 就可以输出日志了。和 std::cout 类似,但是优点就是可以直接支持很多模板类型,例如 STL 的容器和 Fcitx 自身数据类型的直接输出,更加的方便。

Posted in fcitx development | Tagged , , | Leave a comment

Fcitx 5 开发(二)一个按键事件的后半生

当按键被 Fcitx 的前端接收到之后,首先它需要找到对应的输入上下文,然后创建对应的按键事件结构:

https://github.com/fcitx/fcitx5/blob/c492be884540b55ee590d0e3312c4889c8bf4300/src/lib/fcitx/event.h#L242

首先对于一个按键来说,我们先要区分和按键相关的好几个不同的值的含义:Code,State,Symbol。Code 表达的是这个按键对应的物理按键,例如键盘上的 A,不论你在什么情况下按 A(Caps Lock / Shift),产生的 Code 是一样的。State,表示了按键发生时键盘的状态,包括了锁定键的状态,比如 Num Lock 和 Caps Lock,还有各种修饰键(Modifier)的状态是否被按下。当然,对于 32 个 Bit 来说,键盘并没有那么多的按键,因此有一些位在 Fcitx 中也被挪作他用,例如 https://github.com/fcitx/fcitx5/blob/c492be884540b55ee590d0e3312c4889c8bf4300/src/lib/fcitx-utils/keysym.h#L51 这个就是新加入的按键是否是重复键的。

Symbol 则是表达了经过键盘布局转换之后得到的符号,一般来说,输入法的逻辑是直接和 Symbol 打交道的,而不关心从 Code 到 Symbol 之间的转换。Fcitx 的 Symbol 对应的数值是采用和 X11 Symbol 一样的值来简化判断,这样在大部分情况下都不需要重新进行映射。

当创建好对应的 KeyEvent 结构之后,就会把他放到整个 Fcitx 的事件处理当中。这里的事件仅表示和 Fcitx 主体逻辑相关的事件,都是抽象的和 Fcitx 自身逻辑相关的(例如界面是否需要更新 / 发生了按键 / 提交文本),不可和 Fcitx 的事件循环(仅和 IO 相关)混为一谈。

具体来说,则总是通过 Instance 类的这个函数来处理一个新的事件 https://github.com/fcitx/fcitx5/blob/c492be884540b55ee590d0e3312c4889c8bf4300/src/lib/fcitx/instance.h#L66

里面具体处理分为三个阶段,因为输入法是核心,所以事件处理的顺序是围绕着 Engine 构建的。总共分为“在输入法之前,输入法,在输入法之后”三个阶段。当然,内部还有保留的 ReservedFirst 和 ReservedLast 用于保证某些特别的事件会总在最初或者最后被执行,一般用户不能使用这两个阶段。

需要关注某些事件的模块,可以通过 https://github.com/fcitx/fcitx5/blob/c492be884540b55ee590d0e3312c4889c8bf4300/src/lib/fcitx/instance.h#L70 来注册回调函数,这样就会在对应的阶段被调用。

所有的事件都有两个属性:accepted 和 filtered。accepted 控制的是之前 postEvent 的返回值,而 filtered 则控制了事件的处理流程,当一个事件被 filter 之后,它之后的回调函数则都不会被调用。通常这两个是同时设置的,因此有一个 filterAndAccept 来同时进行这两个操作。

这里事件里面,按键事件是最特别的一种,只有它可以被 filter,其他大部分事件则都不可能被 filter。这主要是为了保证逻辑上这些事件处理的一致性,而避免导致问题。

其中,Fcitx 自身的逻辑,也都是构建在这些 API 之上的。例如切换输入法的按键等。当按键一个个经过不同的 handler 处理之后,得到的结果将根据不同的 frontend 返回给不同的程序。对于按键这个事件本身而言,也只有两种结果,处理或者不处理。从接口的角度来说,实际上并不那么需要设计成处理 / 不处理,而只需要在不处理的时候生成一个按键事件给程序就可以了。只是在实践中,不同的 Toolkit 对于生成事件的态度差别太大,因此维持原始事件的数据结构的状态是一个保证许多功能正常工作的方式。因此返回的结果也才变成了“处理/不处理”这样的情况。

在 Fcitx 5 中,系统的键盘布局和分组是绑定的,如果在分组中使用其他的布局的话,会中间再经过一个只对 Fcitx 自身可见的转换。这也就是为什么 KeyEvent 中有三个不同的按键结果:

1、OrigKey:来自原始的系统键盘转换的结果
2、RawKey:经过 Fcitx 内部布局转换的结果
3、Key:Key 经过 Normalize 之后的结果。当然,这个 Normalize 并没有什么神秘的,而是方便输入法实现自己的功能。例如,把按键的 Modifier 过滤为只有几个常见组合键的状态(去掉 CapsLock / NumLock 等)。对于输出字符的按键,则去掉 Shift(避免 CapsLock 下的 A 和 Shift + a 判断需要不同的代码),简单来说就是方便输入法实现的小功能。

输入法或者其他模块可以根据自身逻辑处理按键,并根据需要更新界面信息。和 Fcitx 4 不同的是,每个输入上下文的状态是独立的,其中也包括了界面相关的信息。这在 Fcitx 4 中则是全局共享的。这也主要是为了支持在多个显示服务器下可以采用多个焦点,不互相冲突。

界面根据对应输入上下文的显示服务器,则会选择对应的界面进行显示。例如 Fcitx 5 可以支持同时连接不同的 X 服务器,界面就会根据具体的 X 服务器在对应的服务器上进行渲染。(主要指 classicui 的实现支持这个功能)。

Posted in fcitx development | Tagged , | Leave a comment