Author Archives: csslayer

开发输入法是一种妥协的艺术

很久很久以前,我还没有在用 Linux 的那个时候,那会儿还在用 Windows 上的搜狗输入法。有时候经常就会好奇一件事,为什么输入法的更新日志里,经常会有「修复和XXX程序的兼容性」,「修复和YYY程序的兼容性」,难道他们不应该采用一套统一的接口吗? 几年以后当我开始在 Linux 下开发输入法之后,我终于了解了一切…… 有些东西其实还是颇为为难的,我就来说一下曾经处理过的bug(有些解决,有些未解决,或者难以解决)。 1、LibreOffice 的 crash 简单来说原理就是在某个 Qt 调用 IM Module 的函数里调用某个函数可能会导致无限递归。这个相对来说是比较容易修复的,只需要把 IM Module 调用那个函数的移动到事件队列里延迟调用就可以避免递归了。但这个问题并不会在其他任何 Qt 程序中出现,相信也只是在某个 LibreOffice 的版本无意之中导致的。说实话这种问题并没有一种办法归结为是谁的“过错”,毕竟我相信相关的 API 并没有相应的文档来定义这么细节的调用是不合法的或者可能导致问题。 2、Gtk 的 Client Side Input Panel 的语言 tag 失效 Fcitx 5 有一个功能,让 Pango … Continue reading

Posted in 日志 | 5 Comments

Fcitx 5 and multiple wayland compositor

Actually there is nothing so special about this feature, it’s just come freely with the multiple X server support. I just realized that WAYLAND_SOCKET passed from compositor can be just sent via DBus to the actual fcitx5 server, without the … Continue reading

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

One year in Fcitx 5

Fcitx 5 first release is in 2020/11/2, and as of today, we have reached the 13th release of Fcitx 5. What happened to Fcitx 5 within this whole year of development? 1. Best Wayland support on Linux As of today, … Continue reading

Posted in fcitx development | Tagged , , , | 1 Comment

Why surrounding text is the worst feature in the Linux input method world

This is mainly a complain about how mess this feature is and why no one could reliably use it. To give people some background, surrounding text is about the feature that an application can notify the input method what are … Continue reading

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

上下跳动的文字

我觉得我自从手搓几个low-level的文本绘制之后这个问题其实已经变成专家了。问题本身其实还是很有趣的,这里特别总结一下。 不少人可能都注意到了 Linux 下面有时候会有一种奇怪的现象,就是你输入文字的时候,一旦输入了汉字,汉字可能会把整行文字的位置降低。删除掉汉字的时候,则又会恢复到原本。这是为什么呢? 其实道理是很简单的,就是你这一行文字混合了两种不同的字体。为什么明明没有单独配置但是却使用了不同的字体?因为系统默认使用的英文字体本身,可能并不包含汉字。因此当需要显示汉字(或者其他任何不存在于这个字体的字符)时,就只能回落(fallback)到另外的字体上。你也许注意到了,即使两种字体配置为同一个大小(point),但是实际显示在屏幕上的大小可能是不同的。当两个字体同时在一行文本中使用的时候,为了将他们对齐,则需要使用一个标准将两个字体的文本对齐。这个标准就是基线(baseline)。 这里还有两个重要的线 ascent 和 descent。ascent 就是从 baseline 到字体的最高点,descent 就是 baseline 到字体的最低点。可以假想一下,当另一个字体混入的时候,如果它的 ascent 高于原本字体的 ascent,自然就需要将文本整体“下推”。 通过辅助线,我们可以明显观察到 DejaVu 和中文字体组合之后可以出现明显的下沉现象。 对于编辑器来说,只有两种方式,一种允许每行的高度不同,从而适配文字本身的大小, 另一种则是每行高度相同,但带来的副作用可能是会对 fallback 到的较高的字体砍头去尾。 这里有一个展示了 katepart 曾经长时间存在的文字渲染问题,当字体可能下推文本过多时,超过了原本的行高,则不得不砍掉了一些。右侧是经过我修复之后的 katepart。 这里所谓的修复是什么呢?其实非常的简单,就是把“下推”的文字拉回原本只有单个字体的基线位置。简单的来说,就是进行这样的运算:在 y 轴上偏移一个这样的数值:(渲染文本的整体 ascent – 字体本身的 ascent)。 这样运算之后,那些并非 fallback 的字符将不会被「下推」,而保持在原始的位置。fallback 到其他字体的字符则会对应的上拉一些位置。你可能会问了,这样似乎并没有解决字体被砍头的问题啊?确实,但字体设计的时候,一般会在顶部留有余地不会紧密排列,经过这样调整之后,反而会让大部分即使是 … Continue reading

Posted in Linux | Tagged , | Leave a comment