Color Emoji support in OpenType

Behdad Esfahbod and Stuart Gill
Google

In this proposal we specify how to extend OpenType to allow fonts with embedded color images as glyphs.

One of the goals of this proposal is to reuse the existing structures of EBDT / EBLC tables and introduce new values for the existing fields where feasible.  If and when this proposal is merged into the OpenType standard, the new features will be used with EBDT / EBLC tables proper.  Until then, two new tables are introduced:

Add two new tables CBDT / CBLC that are backward compatible with EBDT / EBLC respectively, but add new formats for supporting color bitmaps.

Uncompressed color bitmaps

In this extension, we allocate the value ‘32’ of the bitDepth field of bitmapSizeTable struct defined in the EBLC table, when used in the CBLC table, to identify color bitmaps with 8-bit blue/green/red/alpha channels per pixel, encoded in that order for each pixel (referred to as BGRA from hereon).  The color channels represent pre-multiplied color and are encode colors in the sRGB colorspace.  For example, the color “full-green with half translucency” is encoded as \x00\x80\x00\x80, and not \x00\xFF\x00\x80.

All imageFormat values defined in the EBDT / EBLC tables are valid for use with this extension.

Compressed color bitmaps

Images for each individual glyph are stored as straight PNG data.  Only the following chunks are allowed in such PNG data: IHDR, PLTE, tRNS, sRGB, IDAT, and IEND.  If other chunks are present, the behavior is undefined.  The image data shall be in the sRGB colorspace, regardless of color information that may be present in other chunks in the PNG data.  The individual images must have the same size as expected by the table in the bitmap metrics.

There are three new imageFormat values with PNG images: one with smallGlyphMetrics, one with bigGlyphMetrics, and one without glyph metrics.  Only the value ‘32’ of the bitDepth field of bitmapSizeTable struct is supported at this time, regardless of the number of colors in the PNG images.

Format 17: small metrics, PNG image data

Format 18: big metrics, PNG image data

Format 19: metrics in CBLC, PNG image data

The image format numbers were specifically chosen to not conflict with those in the EBDT table and so allow for a possible consolidation in the future. Further image format numbers beyond those defined are reserved for future extensions as to the image type and/or the metadata.

Discussion

The aim of this specification is to enable support for color-emoji-only fonts.  It is recommended that such fonts include no ‘glyf’ table, and as such be bitmap-only fonts.  In the presence of color and non-color strikes in the same font, it is currently unspecified which bitmap a conformant client will choose for rendering.

In the presence of color images and a client that does not support color, the color images may be converted to colorless opacity maps in a way similar to:

where b, g, r, and a are the color and alpha components of the input pixel normalized to [0.0,1.0], and opacity is the output opacity value for the pixel (0.0 means transparent, 1.0 means fully opaque).  This formula undoes the premultiplication of color channels, applies sRGB-like gamma-correction, computes luminosity, and combines with pixel alpha to get to a final opacity level for the pixel.

Companions

See the color-emoji project for tools generating fonts under this specification and patchsets to render such fonts.

Revision History

May 2013 Initial public release.