Hi Michael, Are you thinking of the SVG in OpenType proposal from Adobe and Mozilla? Indeed, it would be nice to have support for that too, but it seems like a much more ambitious project. There are demos at https://people.mozilla.org/~jkew/opentype-svg/soccer.html, and a draft spec from Adobe at https://lists.w3.org/Archives/Public/public-svgopentype/2011Oct/0000.html.
The fonts I was thinking about are much simpler; they only embed static raster images. The full spec is below: http://www.microsoft.com/typography/otspec/cbdt.htm http://www.microsoft.com/typography/otspec/cblc.htm But I imagine Xft doesn't need to be aware of the low-level details, since FreeType already has support for this. Clément. On 12/18/2015 02:16 AM, Michael Titke wrote: > 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. >> >> >> >> _______________________________________________ [email protected]: >> X.Org support Archives: http://lists.freedesktop.org/archives/xorg >> Info: http://lists.x.org/mailman/listinfo/xorg Your subscription >> address: %(user_address)s > > > > _______________________________________________ [email protected]: > X.Org support Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.x.org/mailman/listinfo/xorg Your subscription > address: %(user_address)s >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
