Tag Archives: Linux

Analysis on a recent issue between Vivaldi and fcitx5-gtk

This article intends to explain the technical details between a issue happens when using fcitx5 on Vivaldi. I’m not a Vivaldi user and Vivaldi is not fully open source, so I can’t really comment what change actually caused this, but … Continue reading

Posted in 日志 | Tagged , , , | 1 Comment

Chrome/Chromium 今日 Wayland 输入法支持现状

似乎有不少人总是有疑问,Chrome的Wayland输入法支持到底是什么情况,能不能输入,支不支持,那么就姑且来总结一番。本文仅代表写作时的状态,不代表后续的情况。(以下用 Chrome 指代 Chrome/Chromium)。 首先简单介绍一下 Chrome 对 Wayland 支持的情况。对于 Chrome 这种跨平台的项目来说,肯定有自己的抽象层,从而能够高效地利用对应平台的 GPU,图形栈。现阶段来说,这一层抽象的项目的名称是 Ozone,更多详细的介绍可以参考 https://chromium.googlesource.com/chromium/src.git/+/HEAD/docs/ozone_overview.md。这里的描述是这样的:Ozone 是在使用了底层输入和图形的 Aura 窗口系统下的平台抽象层。一旦完成,这个抽象将支持各种系统,包括嵌入式 SoC,或者新的 Linux X11 替代:Wayland/Mir 来启动 Aura。 现在如果要在 Wayland 上用原生 Wayland 而不是 XWayland 来显示,那么将要使用 Ozone 作为它的图形栈。那么 Ozone 有什么样的输入法支持呢?在很长的一段时间内,它的输入法支持只有 text_input_v1,并且需要使用 –enable-wayland-ime 来启用。对于不了解 Wayland 输入法架构的人来说,这里对 Wayland … Continue reading

Posted in fcitx development | Tagged , , , , | 7 Comments

New compose mode in Fcitx 5

1.5MB gif for demostration. Basically it allows you to use backspace to modify the compose sequence, or type character directly with dead keys (e.g. you may simply press dead key once and continue to type). If you want the old … Continue reading

Posted in fcitx development | Tagged , , | Leave a 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