Note this does not change image files.
- modify emoji_builder so we can use a flag to control whether to use
big or small glyph metrics. android has legacy tooling that expects
small metrics. we leave the default in emoji_builder to use big metrics
but in the makefile default the flag we pass to request small metrics.
eventually this should shake out to big metrics.
- support more flags by default (not all yet). Note we omit some in the
Makefile that we use aliases for-- we don't need their images.
- add aliases for some new flags
- remove new flags from 'unknown flag aliases' list
- unalias some emoji we will have custom images for
- bump version number
- add annnotations file for u11 new and changed emoji
Standard Unicode (emoji v5) does not define skin tones for wrestlers,
but android does. Alias the skin tone variants of the non-gender-
specific emoji to the corresponding male emoji, as we do for the
non-skin-tone version.
This is a rewrite of add_glyphs in third_party/color_emoji. The
primary motivation was to move special aliasing rules out of that
code and use an external aliases file instead. This new version
is a bit more thorough about aliasing, and hopefully a little
easier to read.
The new add_glyphs takes its parameters using keywords, so
the invocation in the Makefile changed (as well as the path to
the tool).
emoji_aliases.txt was extended to add the flag aliases that were
formerly defined in the old add_glyphs code.
add_aliases was modified so the name of the alias file could be
passed in as a parameter to the main utility function that reads
the alias mapping from the file.
The new code expects all glyphs used by the template GSUB tables
to be named in the GlyphOrder table, but doesn't require the cmap
and hmtx table to be fleshed out. The new code fleshes these out
when it processes the sequences to add. As a result the cmap and
hmtx tables in the template were truncated.
The new code also sorts the GlyphOrder table when it extends/rebuilds
it.
This maps a sequence of codepoints to another sequence, where the
first sequence should be an alias to the second.
Initial data contains emoji sequences where we expect an image named
according to the second sequence, but want to support the first
sequence with the same image.
Doug Felt