Add support for BGRA glyphs and scaling

Scaling is done by averaging all relevant pixel, which gives much better result than nearest pixel sampling while staying simple enough and not too computationally expensive.

This enables color emoji rendering support.

I tested this on st and dmenu, both work fine once fontconfig is setup to prepend color emoji fonts. rxvt-unicode requires a small patch.

dmenu:

urxvt:

st:

added 1 commit

• 2b19aac9 - Add support for BGRA glyphs and scaling

Compare with previous version

added 1 commit

• 8d053e4d - Add support for BGRA glyphs and scaling

Compare with previous version

added 1 commit

• 0e4716a4 - Add support for BGRA glyphs and scaling

Compare with previous version

@keithp Hello, would you be able to direct me towards who would be a good candidate to review this ? Shall I post this to the mailing list as well ?

Actually there is one remaining issue, bgra glyphs should be composited ignoring the color (except for alpha). Will fix this first.

added 1 commit

• eef052d9 - Add support for BGRA glyphs display and scaling

Compare with previous version

The compositing issue could unfortunately not be solved using XRender glyphs, as those use the glyph bitmap as a mask in the compositing operation, which has the unfortunate side effect of making compositing of the glyph use component-alpha, which breaks the Over operator we would want.

In order to fix this, BGRA glyphs now use a Picture and go through an explicit XRenderComposite call.

Here are a few updated screenshots, along with the Xft api style they use (as Xft provides 3 separate codepaths to display text: DrawString/DrawGlyphSpec/DrawGlyphFontSpec)

Unpatched dmenu (XftDrawStringUtf8)

Slightly patched urxvt (XftDrawGlyphSpec)

Slightly patched (for broken xOff handling) pango (pangoview here) (XXftDrawGlyphSpec/ftGlyphSpecRender)

Unpatched st (XftDrawGlyphFontSpec)

mentioned in issue #6 (closed)

added 1 commit

• fe41537b - Add support for BGRA glyphs display and scaling

Compare with previous version

Updated the commit to fix an issue where slanting tranform gets applied to mono bitmap fonts, leading to ugly display. Also slightly tweaked the scaling code to compute coordinates of the center of the target pixel instead of its corner.

@keithp Any pointer on who could give this a review ? Should I post that on the mailing list as well ?

Just tested this patch and it is working for me with unpatched st. It would be great for lightweight terminal users to get this reviewed & merged.

In the meantime, I've created some AUR packages for Arch Linux users that include the patch:

• libxft-bgra
• lib32-libxft-bgra

Any chance someone could put together a Void package for this? With the last update being 10 months ago and this MR being open for 3 months, something tells me this project is officially dead (or at least dead enough that it'll never merge)

I imagine libXft is not very high priority anymore, and the few people who qualify to review the patch are likely quite busy. However libXft is still used by a lot of projects, and will likely continue to be relied on until Xwayland is retired (so, not anytime soon), so I (unsurprisingly) think it makes sense to to merge this.

I did send that change through the xorg mailing list (and the xorg-devel one), did not get any feedback either. It would be nice to get some, even if it is "plan to review, did not get the time to do it yet" or "libXft is abandonned, wont merge" or even "We dont want emoji support in libXft".

@alanc @keithp Any chance to get your input on that ?

Is anyone using this patch able to display both non-latin characters and color emoji in st? It seems that with a color emoji font enabled st is unable to use any fallback font other than the color emoji font. (Arch Linux, using the patched AUR package above !1 (comment 388317))

With a b+w emoji font, Greek and CJK characters appear correctly:

user@host: lsof -p $(ps -o pid -C st | tail -1) | grep fonts

st      43691  user  mem    REG              254,1 19647736  3436134 /usr/share/fonts/TTF/msyh.ttc
st      43691  user  mem    REG              254,1  1261972  3435232 /usr/share/fonts/nerd-fonts-complete/ttf/Noto Emoji Nerd Font Complete.ttf
st      43691  user  mem    REG              254,1  3296260  3434898 /usr/share/fonts/nerd-fonts-complete/otf/Inconsolata Nerd Font Complete Mono.otf

With a color emoji font, st doesn't display Greek or CJK characters:

user@host: lsof -p $(ps -o pid -C st | tail -1) | grep fonts

st      43335  user  mem    REG              254,1 21992172  3933062 /usr/share/fonts/joypixels/JoyPixels.ttf
st      43335  user  mem    REG              254,1  3296260  3434898 /usr/share/fonts/nerd-fonts-complete/otf/Inconsolata Nerd Font Complete Mono.otf

This does not seem to be related to the patch itself, but with the fontconfig fallback logic. An unpatched libXft with the fontconfig fallback to a color emoji prevents st from displaying CJK characters as well.

Its likely that the fontconfig config must be made smarter (Here I used https://github.com/stove-panini/fontconfig-emoji)

You're right, this seems to be a problem with fontconfig, not libXft. I got everything to display by reworking my fallback logic to make sure color emoji stay below CJK and Greek fonts. It still seems like there's some unintended behavior here, but not within the scope of this MR

could you hint me a little more on how you reworked your font fallback logic? I guess, with similar *.conf files in ~/.config/fontconfig/conf.d, but from there I'm a bit stuck..

For me if you set the first character on a line into an emoji on st, characters start disappearing after another character has been typed. You can see a video of it here. You can simulate what I'm doing by setting the PS1 variable to nothing (I was trying to make a prompt that was an emoji, which was how I discovered this) emoji

added 1 commit

• 7808631e - Add support for BGRA glyphs display and scaling

Compare with previous version

@webb Good catch, this bug seems to only trigger with emojis that are rendered as single width character (I'd say wrongly in the case of the spider emoji, but I suspect the issue is in wcwidth itself).

This led me to find an issue in the XftDrawGiyphFontSpec code path that st is using, and fixed that in the updated commit, this should work fine now.

@mawww I'm still having the same issue