较新的FreeType支持多色,但cairo-1.14.6没有默认开启支持。hexchain指出修改cairo源码一行代码即可:
|
|
然后编译安装cairo。
可以安装aur/cairo-coloredemoji
。
huiyiqun指出,infinality-bundle用户应该:
/etc/fonts/conf.d/82-no-embedded-bitmaps.conf
安装Noto Color Emoji字体,Arch Linux可以装extra/noto-fonts-emoji
。
在~/.config/fontconfig/fonts.conf
(更准确点应用$XDG_CONFIG_HOME
)中添加下面两个<match>
标签(hexchain提供)。
|
|
可以用fc-match -s monospace
、fc-match -s sans
、fc-match -s sans-serif
确定字体选择顺序。我这里Noto Color Emoji只能排到第二,不明原因。
推荐使用hexchain的配置:https://gist.github.com/hexchain/47f550472e79d0805060。
经过以上两步配置,理应可以使用Noto Color Emoji字体了。但对于Monospace字体,emoji字符显示宽度为1,会与其后的字符重叠。
在终端模拟器中,字符是按列显示的,因此有宽度的概念。vte把emoji字符当作1,因此显示时会与之后的字符重叠。
以终端模拟器termite使用的community/vte3-ng
为例。修改源码src/vte.cc:_vte_unichar_width
,让该函数对于某些Noto Color Emoji提供的Unicode block返回2。此处我硬编码了几个用到的Unicode block,不全:
Arch Linux可以装aur/vte3-ng-fullwidth-emoji
。该patch另外修复了canonical mode下退格宽字符,终端模拟器只移动一格光标的问题(其实应该是kernel的bug,不妨头痛医脚)。
wcwidth
宽度对于ncurses应用,会用wcwidth
计算待擦除字符的宽度。仅经过上面的配置,wcwidth
仍认为emoji字符宽度为1,擦除时宽度计算不对,可能导致一些字符残余在屏幕上。
wcwidth
对字符宽度的计算由locale决定,比如对于常用的en_US.UTF-8
等,glibc提供的/usr/share/i18n/charmaps/UTF-8.gz
中WIDTH
、END WIDTH
区块给出了字符宽度信息。但其中没有列出Emoji字符,因此宽度将用缺省值1。
我用https://gist.github.com/MaskRay/86b71b50d30cfffbca7a重新生成一个UTF-8
,gzip压缩后覆盖/usr/share/i18n/charmaps/UTF-8.gz
,然后执行locale-gen
。修改后,可以用https://gist.github.com/MaskRay/8042e39dc822a57c217f确定wcwidth
计算出来的宽度确实变更了。
|
|
为了这张笑脸真是一把辛酸泪……
Monospace实现很困难。要画出好看的Emoji,势必要用fullwidth,这个属性如果能由字体提供是再好不过的。对于底层的glibc、glib
,它们并不能知道字体,但又不得不规定字符宽度,一不小心即与字体的实际宽度产生冲突。翻了翻http://www.unicode.org/Public/UCD/latest/ucd/等,好多地方分散地提到了fullwidth,比如Halfwidth and Fullwidth Forms、East Asian Width等,不同实现对这些概念的理解会有偏差……
在neovim里写这篇文章时又发现neovim对字符宽度也有问题,src/nvim/mbyte.c:utf_char2cells
看上去是无辜的,所以谁坏掉了呢?