Open Radar

 
It's no secret that Emoji are wildly popular, especially on social networks. As a result, many companies want to differentiate themselves by having a unique set of Emojis. One recent example is Twitter: here is a sample of the press generated when they introduced their own symbols:

http://www.theverge.com/2014/4/2/5576280/twitter-gets-emoji-web-support
http://thenextweb.com/twitter/2014/04/02/boxes-twitter-com-now-supports-emoji-characters/
http://www.engadget.com/2014/04/02/twitter-now-shows-emoji-characters-on-web/

These Emoji images are also open source:

http://twitter.github.io/twemoji/

As a result, people are looking for ways to create a TrueType font containing Emoji bitmaps. This font will be embedded in iOS and OS X native apps. Conceivably, it could also be used as a web font.

Using Emoji as a part of a product's branding is not dissimilar to Apple's own use of Myriad Pro in marketing materials and San Francisco on devices. A font plays a huge role in a customer's perception of a product.

The problem is that there is no documentation on how to generate an Emoji font that can be used with iOS and OS X.

We are using the following document from 2014 as the most recent reference for the TrueType format:

https://developer.apple.com/fonts/TrueType-Reference-Manual/

The SFNTLayoutTypes.h file in the CoreText framework is also missing key pieces of information needed to construct an Emoji font. The file suggests consulting https://developer.apple.com/fonts/registry/ for further information. That page no longer exists.

Apple's tools for working with fonts on OS X have not been updated since October 10th, 2011. They do not support Emoji. If Apple has a internal tool for constructing these fonts, it would be very helpful to third-party developers.
 
Specifically, the following items in Apple Color Emoji.ttf are not documented:

• Feature type 444 (0x01bc)
• Feature selector 0 and 1 for feature type 444 (0x1bc)
• The purpose of kMORXCoverLogicalOrder
• A special glyph id 65535 in a swash lookup table

For the gory details, read on…

——

By reverse engineering, we can determine the following characteristics about the standard Emoji font on iOS and OS X:

• The file is located at /System/Library/Fonts/Apple Color Emoji.ttf. As of OS X 10.11, the version is 11.0d7e1.

• The font has no embedded copyright. It's the only Apple font without this information. I'm guessing this oversight is because the Emoji font is compiled by special tools, not created in a font editor where a designer would notice it missing.

• The font contains the following required tables:

	cmap - character to glyph mapping
	glyf - glyph data
	head - font header
	hhea - horizontal header
	hmtx - horizontal metrics
	loca - index to location
	maxp - maximum profile
	name - font naming (localized)
	post - PostScript

• The font contains the following optional tables:

	OS/2 - OS/2
	morx - extended glyph metamorphosis
	sbix - bitmap data in a standard graphics format
	trak - tracking which allows adjustment to normal interglyph spacing
	vhea - contains information needed for vertical fonts
	vmtx - the vertical spacing for each glyph in vertical font

• The 'sbix' (extended bitmaps) table contains seven strikes with PNG data at 72 dpi for the following sizes:

	20x20, 32x32, 40x40, 48x48, 64x64, 96x96 and 160x160

• Each of these 'sbix' resources has a corresponding 'glyf' resource which defines two contours for a 800x800 bounding box.

• Some 'glyf' resources, such as those for the regional indicator symbols, contain multiple contours but no data in the 'sbix' strikes.

• The left and top side bearings for the glyphs with 'sbix' resources are both 0. The width and height metrics for these glyphs is 800.

• All glyphs have horizontal ('hmtx') and vertical ('vmtx') metrics. They all have PostScript names ('post'), too.

• Some, but not all, glyphs have entries in the 'cmap' table. For example, only the WHITE UP POINTING INDEX (U+261D) Emoji is included mapping code point 0x261d to the glyph named "u261D.0". The glyphs for "u261D.1" through "u261D.5", which are used for the different skin tones, are not in the character map.

Similarly, U+1F1FF U+1F1FC (regional indicator symbols "Z" & "W" for Zimbabwe) has no character map entry. There is a glyph with the name "u1F1FF_u1F1FC" that has entries in both the 'glyf' and 'sbix' tables. This glyph contains a bitmap for the country's flag.

Any glyph that is a composed character in Emoji, can't represented in a 'cmap' because of its one-to-one mapping between a code point and a glyph name.

• Additional information for the glyphs is contained in the 'morx' table. The documentation describes the table thusly:

"The extended glyph metamorphosis table (tag name: 'morx') allows you to specify a set of transformations that can apply to the glyphs of your font. These transformations, called text features, are essential for writing systems such as Arabic or Hindi that require changes to glyphs and words depending on context. Text features are also useful for writing systems, such as Roman, that can use effects such as ligatures and cursive connections to enhance the appearance of text."

https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6morx.html

Ligatures seem like a good fit for mapping multiple glyphs (e.g. regional indicator symbols) into another unique glyph (e.g. a flag). Swashes would be useful for switching glyphs based on a preceding glyph (e.g. a U+FE0F variation selector).

Removing the 'morx' table from the Emoji font causes the combined characters to split into their individual glyphs. For example, flags become regional indicator symbols and skin tones are shown with two bitmap glyphs. Clearly, this table is used to combine sequences of Unicode code points into matching glyphs. Unfortunately, there are key pieces of information missing that would let you create your own 'morx' table.

We can see that the 'morx' table in the Apple Color Emoji font contains one chain with 5 feature arrays and 6 metamorphosis subtables.

The first and second features contain ligatures (kLigaturesType) while the last feature is the all features type (kAllTypographicFeaturesType). The third and fourth features use an undocumented feature type of 444 (0x01bc). The current list of feature types has no information about Emoji or how ligatures are used to display them:

https://developer.apple.com/fonts/TrueType-Reference-Manual/RM09/AppendixF.html

The ligature features have both an on and off selector (kRequiredLigaturesOnSelector first, then kRequiredLigaturesOffSelector). The third and fourth feature entries (444) have undocumented selectors of 0 and 1, respectively.

The first four subtables contain ligatures (MorxLigatureSubtable). The last two contain swashes (MortSwashSubtable).

The fourth ligature table has a coverage of 0x30000002. The documentation states that this is reserved, while SFNTLayoutTypes.h indicates that this is a combination of kMORXCoverIgnoreVertical and kMORXCoverLogicalOrder. There is no further information about kMORXCoverLogicalOrder.

The first swash subtable uses a lookup table to map glyph 42 ("uniFE0F" - Emoji variation selector) and 43 ("ZWJ" - zero width joiner). Both are mapped to 65535, which is a glyph id that does not exist. There is no documentation about this special mapping.

The second swash subtable also contains a lookup table that maps every glyph in the font to itself. That seems wrong.

• The 'morx' table version 2 is supported in all versions of OS X and iOS. Support for the 'morx' table version 3 is planned for future releases of iOS and OS X. Maybe the future is now.