On 12/30/2015 07:11 AM, Richard Stallman wrote: > To correct this technical problem entails (1) putting support into X > display for these features and (2) making Emacs interface to them. > Since (1) is the hard job and (2) is comparatively easy, our proper > technical response is to urge people to work on (1). Would you like > to work on it? If anyone knows a libXft maintainer, I'll be happy to talk to them; my email to their mailing list gathered exactly one response, which I can unfortunately not make any sense of: }} -------- Forwarded Message -------- }} Subject: Re: Color bitmap support in Xft? }} Date: Fri, 18 Dec 2015 08:16:37 +0100 }} From: Michael Titke }} To: xorg@lists.x.org }} }} Just add a video mode font (we'll need to "typeset" videos intext anyway - what was layout then?) and replace user input with random noise where DSP would have told those smart ones ... }} }} On 17/12/2015 21:23, Clément Pit--Claudel wrote: }} > Hi all, }} > }} > I'm looking into adding support for color emoji to Emacs. Color emoji use a new feature of OpenType fonts that allows font designers to embed full-color images in a font for certain glyphs. Fonts such as Google Noto Emoji or Apple Color Emoji thus have a table mapping certain Unicode points to raster color images. This feature is frequently used on smartphones, and was more recently added to Chrome and Firefox (both get it throught Freetype). }} > }} > Freetype has support for these multicolor glyphs since version 2.5 (2013). So does FontConfig (and, apparently, Skia). However, it does not seem to be possible to use this feature through Xft. }} > Has there been efforts to support it? }} > }} > IIUC, the required changes would involve extending case matches that look at the FT_Pixel_Mode enumeration (it gained a new member FT_PIXEL_MODE_BGRA), and passing an extra flag to Freetype. Here is the relevant documentation: }} > }} >> FT_PIXEL_MODE_BGRA }} >> }} >> An image with four 8-bit channels per pixel, representing a color }} >> image (such as emoticons) with alpha channel. For each pixel, the }} >> format is BGRA, which means, the blue channel comes first in memory. }} >> The color channels are pre-multiplied and in the sRGB colorspace. For }} >> example, full red at half-translucent opacity will be represented as }} >> ‘00,00,80,80’, not ‘00,00,FF,80’. See also FT_LOAD_COLOR. }} >> FT_LOAD_COLOR }} >> }} >> This flag is used to request loading of color embedded-bitmap }} >> images. The resulting color bitmaps, if available, will have the }} >> FT_PIXEL_MODE_BGRA format. When the flag is not used and color }} >> bitmaps are found, they will be converted to 256-level gray bitmaps }} >> transparently. Those bitmaps will be in the FT_PIXEL_MODE_GRAY }} >> format }} > Has such an extension been discussed before? Or am I taking the wrong approach? }} > }} > Clément. On the other hand, the person who implemented support in Freetype said that he would look into it (in an exchange at https://github.com/googlei18n/color-emoji/issues/5). Having no experience with this (and seeing that a patch adding support for it was proposed to libXft at http://lists.x.org/archives/xorg-devel/2015-August/047175.html last August but received no responses), I'm not sure what more to do. Advice is very welcome though! Clément.