Color bitmap support in Xft?

[Clément Pit--Claudel]

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.
>> 
>> 
>> 
>> _______________________________________________ xorg at lists.x.org:
>> X.Org support Archives: http://lists.freedesktop.org/archives/xorg 
>> Info: http://lists.x.org/mailman/listinfo/xorg Your subscription
>> address: %(user_address)s
> 
> 
> 
> _______________________________________________ xorg at lists.x.org:
> X.Org support Archives: http://lists.freedesktop.org/archives/xorg 
> Info: http://lists.x.org/mailman/listinfo/xorg Your subscription
> address: %(user_address)s
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20151218/16a838a5/attachment.sig>