Re: Emacs Mac port

[Clément Pit--Claudel]

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 <address@hidden>
}} To: address@hidden
}}
}} 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.

signature.asc
Description: OpenPGP digital signature