Submitting Emoji Proposals
Anyone can submit a proposal for an emoji character, but
the proposal needs to have all the right information for it to
have a chance of being accepted.
This page describes the process of submitting a proposal,
including how to submit a proposal,
the selection factors that
need to be addressed in each proposal, guidelines on presenting
evidence of frequency, and
the process and timeline for
acceptance.
Not all new emoji require new characters. Thus this page
also describes the process of proposing that:
Please read this entire page before preparing a proposal. In particular:
existing characters be changed
to be emoji, or
additional emoji
sequences be added as valid or RGI.
Proposals are likely to be declined unless they are complete and adhere to the submission instructions. Other proposals may be returned to the submitter for adjustment based on subcommittee review.
- Scan the list of Emoji Requests to see whether your proposed emoji have already been submitted. If the status is Declined, it may not be worth the effort to make a proposal.
- Make sure you understand this whole document, especially the Selection
Factors.- Read the Limitations on Emoji Encoding
section of Emoji Encoding Principles.- Read the Emoji Submission FAQ for common questions and answers.
- Review some Example Submissions to see how previous proposals were constructed.
Submitting a
To submit a proposal for a new emoji, please prepare a document
Proposal
according to the Form
for Emoji Proposals. Your
document
must contain all of the sections shown in the form,
and should address, as completely as possible, all of the items
specified there.
Each
proposal document must follow the Form
for Emoji Proposals. When submitting proposals via e-mail, you
must include the title in the Subject line.
Once you
have completed your document, please follow the directions in How
to Submit Proposal Documents to submit it. For timelines, see Process
and Timeline.
Form
for Emoji Proposals
Normally, each proposal is for a single emoji. A group of related emoji can be put into a single proposal.
Title: Proposal for Emoji <name(s)>
The <name(s)> must clearly identify each emoji being proposed, such
as Proposal for Emoji: PRAM or Proposal for Emoji: PRAM; STROLLER
Submitter: <name>
The <name(s)> must clearly identify the submitter(s). Use ; between multiple authors.
Date: <date>
When re-submitting revised documents, the document date must still be updated each time.
Identification. Suggested short name
and keywords for the emoji, as in the Emoji List.
- CLDR short name
- CLDR keywords
- Proposed emoji names should be general. Adjectives or other narrowing terminology should be avoided except where necessary to distinguish from an existing character. For example, instead of SWAN FACE, the name should be SWAN. Some existing emoji names deviate from this for historical reasons.
Images. One sample color image and
one sample black&white image for each proposed emoji must
be included in the proposal and in an attached zip file.
These are to illustrate how each character might be
displayed. The format and license must
be as specified in Images.
Zip File.
Please send Zip files
as e-mail attachments. Do not
provide links to file-sharing site URLs, or
include links in the proposals.
License. The proposer must certify
that the images have appropriate licenses for use by the
Unicode Consortium, and list the type of license.
Document. The images must be included in the document at the top in two sizes: 18x18 and 72x72 pixels. The 18x18 image is to provide immediate feedback (to you and the committee) as to whether the image is distinctive enough.
Sort location. A proposed sort
location for the emoji in Emoji Ordering
- Category (such as cat-face)
- The emoji in that category that it should come after (such
as after
WEARY CAT FACE).
(leave blank)
The above items must all be at the top of the first page.
Selection factors — Inclusion. A
section that addresses all Selection
Factors for Inclusion, and for each one provides evidence as
to what degree each of the proposed characters would satisfy
that factor.
- Compatibility
- Expected usage level
- Frequency (must have separate evidence for each proposed emoji)
- Multiple usages
- Use in sequences
- Breaking new ground
- Distinctiveness
- Completeness
Selection factors — Exclusion. A
section that addresses all Selection
Factors for Inclusion, and for each one provides evidence as
to what degree each of the proposed characters would satisfy
that factor.
- Petitions or “frequent requests”
- Overly specific
- Open-ended
- Already representable
- Logos, brands, UI icons, signage, specific people,
specific landmarks, deities- Transient
- Faulty comparison
- Exact Images
- Region Flags Without Code
Other information. Any other
information that would be helpful, such as design
considerations for images.
However, each of the proposed emoji must have full justification, with all information as if it were a separate proposal. So it is better to have separate proposals for each unless they are extremely closely related.
Please:
A proposal may be advanced despite a “cause” argument
- don’t justify the addition of emoji
because they further a “cause”, no matter how worthwhile- don’t include specific code points
(U+XXXXX) for proposed characters- don’t include a filled-out Proposal
Summary Form.
— if other factors are compelling — but will not be advanced because
of it.
The committee will assign code points and fill out the Proposal
Summary Form later in the process. The original proposal may
then be amended to include those, as was done with the Food
emoji characters example below.
The names and images for approved characters may be
changed — sometimes substantially — from what is suggested in
the proposal. Quite often the name is generalized, for example.
A proposal for a brick wall or an iceberg might end up being just for “brick” or “ice” (represented by an ice cube image). The image that a vendor uses typically departs substantially from what
is in the proposal, such as to better fit with the “house
style” for that vendor.
The Emoji Proposals chart contains a set of all proposals for emoji up to the last release. More recent (but not yet accepted) proposals can be found on Provisional Candidates and/or Draft Candidates. As you read these, remember the following key facts:
Example Submissions
- New proposals must follow the current Form for Emoji Proposals. This form may have changed since earlier proposals were submitted. The earliest proposals on The Emoji Proposals chart date from before the Form for Emoji Proposals was in place.
- A proposal may be accepted for reasons in addition to those stated in the proposal.
- A proposal may be accepted in spite of material in the text.
- Proposals sometimes contain material that is irrelevant, or even counterproductive. That material might be ignored by the committee if the proposal is otherwise strong enough.
- A final name and image accepted on the basis of the proposal might differ from what is proposed.
Sequences
Not all new emoji require new characters. People
& Other Proposals
can propose that:
The timeline for these proposals is not as long as for new
existing characters be changed
to be emoji
additional
emoji sequences be added as valid or RGI
characters, since existing characters can be changed to be
emoji or emoji sequences added on a shorter timeline, see Process
and Timeline.
You will need to supply color images, but for these proposals you don't need the black and white images.
Making Existing
Some characters are already encoded in Unicode; they just
Characters be Emoji
aren’t considered emoji (that is, they don’t have emoji
properties). These include the chess
characters, for example. See Extended_Pictographic
for examples
of similar characters.
Note that the color images may deviate quite substantially from the Unicode black & white representative images, such as in the Miscellaneous Symbols block. The following table illustrates the how far the emoji image can vary from the black and white, which can be quite minimal and symbolic.
However, if the Unicode character is completely symbolic, emojification is not appropriate.
B&W Emoji Code Character Name U+26F0 MOUNTAIN U+2699 GEAR U+26F9 PERSON WITH BALL
If a proposal is accepted for recognizing an existing character
B&W Code Character ☶ U+2636 TRIGRAM FOR MOUNTAIN
as an emoji, the outcome would be a change in the Emoji
property value for that character in emoji-data.txt.
New Emoji
Similarly, new sequences can be proposed for addition.
Sequences
These include:
- Making a valid sequence be RGI,
such as a new ZWJ sequence for dumpster fire represented internally by trash can + ZWJ + fire.
Accepting that proposal would result in changes to the data
files emoji-sequences.txt
or
emoji-zwj-sequences.txt.
- Making an invalid sequence be valid, such as allowing
for a skin-tone modifier to apply to a character that it
couldn't before. Accepting that proposal would result in a
change to the Unicode
Emoji specification.
Submission
The submission form is almost the same as the Form for Emoji Proposals, but
Form Mods
with the following changes.
The <TITLE> is changed to one of
The code points of the characters or sequences to be affected
- Proposal for Changing Characters to
Emoji- Proposal for New RGI
Emoji Sequences
- Proposal for New Valid Emoji
Sequences
must be listed in a new item 1.C
Code Points.
Selection factors I, J, and L are not applicable, and
should be marked with N/A.
Images
Images must be supplied in a 'flat' zip file
(without internal folders), and must be sent in e-mail attachments, not as links to file-sharing sites.
Images must be in PNG format with dimensions of 72x72 pixels.
The image should extend to the sides of the cell (ie, no extra
padding). Outside of the main image it should be transparent.
Black & white images must be suitable for fonts. Grayscale is not acceptable. Examples:
The file names must have the following format:
✅ color ✅ black & white ❌ grayscale
Examples:
Non-Unicode members
<name>.png
name= the name of the proposal.Unicode members <vendor>_<hex>.png
vendor= a lowercase word based on a company or
product name, such as adobe, android,
apple, emojination, emojione, emojipedia, emojixpress, fb,
fbm, samsung, twitter, and windows.
<hex>= lowercase hex
value(s) of the form[0-9a-f]{4-6}, separated by _, with all “fe0f”
values removed.Provisional candidates Hex values in the range 100000-10fffd
Draft candidates Draft code points as assigned by the UTC Released characters Assigned code points
✅ = Valid, ❌ = Invalid
New proposal ❌ a195.pngname not descriptive ❌ Yawning_face.pnguppercase ✅ yawning_face.pngAdvanced to provisional candidate ✅ proposed_101234.pngAdvanced to draft candidate ✅ proposed_1f004.pngReleased, supplied by vendors ❌ 1f004.pngmissing vendor name ❌ emoji_1f004.pngbad vendor name ❌ android_1F004.pnguppercase ✅ android_1f004.png❌ apple_002a20e3.pngmissing underbar ✅ apple_002a_20e3.png✅ apple_1f915.png❌ facebook_2639_fe0f.pngfe0f ✅ facebook_2639.png❌ windows_1f3f3_fe0f_200d_1f308.pngfe0f ✅ windows_1f575_200d_2642.png
Duplicate Images
The images supplied for deployed (or in-development)
emoji should represent how the system works in
practice. For example, if a system uses the same glyph for
multiple emoji, then the image should be supplied once for each
emoji. This currently occurs on some systems with:
- gender variants with MALE / FEMALE signs, and the
base. So if the same image is used for person
running and for man
running, then both x_1f3c3.png and x_1f3c3_200d_2642.png
should be supplied, each having the same image.- flags, such as for U.S.
Outlying Islands and the US
- modifier sequences where the
base shows no visible skin
Image Licenses
The images must have appropriate licenses so they can be used
on the Unicode site, such as “public domain”, “licensed for
non-commercial use”, “free to share and use”, or equivalent (CC:
CC0, or BY*). If you have the rights to the image, state that
it meets those conditions, otherwise include a link to a page
indicating that the license for the image does meet those
conditions.
Image Search (or equivalent) can be useful for finding
suitable images for proposed characters.
On Bing,
choose Type > Clipart & License > Public Domain, such as emu.
On Google,
choose Search Tools > Type > Clipart & License > Labeled for noncommercial reuse, such as emu.
You can try filtering for usage rights or license.
Sometimes that’s too narrow, and you can find more images with
a general search, then clicking through to determine whether the
license is suitable.
Selection Factors
There are two kinds of selection factors. Some weigh in
favor of encoding the emoji, and some against. These are listed
in the sections below.
Selection Factors for Inclusion
Initially, the Unicode emoji characters were selected
primarily on the basis of compatibility. The selection factors
have been broadened to include other factors; here are the
factors that the Emoji subcommittee now considers when
assessing possible new emoji. None of these factors alone
determine eligibility or priority: all of the factors together
are taken into consideration. The most important factors for
inclusion are compatibility and expected usage level.
Compatibility.
Are these needed for compatibility with high-use emoji in popular existing systems, such as
Snapchat, Twitter, or QQ?
- For example,
FACE WITH ROLLING EYES.
- For this to be a positive factor,
the proposed emoji must also have evidence of high-frequency
use in that existing system.- Mark this as n/a unless there are compelling examples.
Expected usage level. (See
questions below) Measures that can be presented as evidence
include the following:
Frequency. Is there a high expected
frequency of use?
- This is the most important factor for inclusion.
- There should be high expected usage worldwide, or
high expected usage within a very large user
community. For example, a community can be geographic,
such as users in Latin America or users in Southeast Asia.
The evidence of frequency must follow the format of Evidence of Frequency. In particular, the following must be present:
- Be sure to read the entire section Evidence of Frequency before starting.
Multiple usages. Does the candidate
emoji have notable metaphorical references or symbolism?
- For example,
SHARK is not necessarily only the animal, but also used
for a huckster, in jumping the shark, loan shark, etc. The
CAT FACE,
PIG FACE, or
RABBIT FACE may be used to evoke positive feelings, while
SPIDER may used to evoke negative feelings.
- References for use as an archetype, metaphorical
use, and symbolism may be supplied.- Mark this as n/a unless there are compelling examples.
Use in sequences. Can the candidate
be used in sequences?
- For example, objects associated with professions
or activities are of interest for use in sequences: either
combined with a person using a ZWJ, or just in linear
sequence.- Mark this as n/a unless there are compelling examples.
Breaking new ground. Does the character
represent something that is new and different?
- More weight is given to emoji that convey concepts
that are not simply variants of concepts conveyed by
existing emoji or sequences of existing emoji.- For example, it would be better to proposal an
emoji for a new kind of animal rather than an emoji for a
new breed of dog.- Mark this as Yes or No. If yes, explain why.
Distinctiveness. Explain how and why your
image represents a distinct, visually depictable entity.
- A visually depictable entity can be clearly represented by an emoji-style rendering that is sufficiently recognizable.
- Emoji images are paradigms, semantically representing a class of entities much larger than a specific image. Thus a U+1F37A beer mug represents not just a mug with exactly the shape you see on the screen, filled with beer of exactly that color, but rather beer in general.
- The term recognizable means most people familar with that entity should be able to discern that the representation is intended to depict a paradigm of that particular entity, without foreknowledge.
- The image you supply will not be used in products, but instead needs to demonstrate that the emoji is distinct enough to be recognizable at typical emoji sizes, such as 18×18 pixels on mobile phone screens.
- The term entity includes not only concrete objects, but also actions or emotions.
- Actions or activities may be represented by capturing a person or object in the midst of that action. Thus U+1F3C3 person running also represents the action of running, and U+1F622 crying face also represents crying.
- Emotions or mental states can be represented by a face or body exhibiting that emotion or state. Thus U+1F620 angry face also represents being angry, or anger.
- A representation may use commonly understood “comic-style” visual elements, such as U+1F4AD thought bubble, motion lines as in U+1F44B waving hand and U+1F5E3 speaking head, or other signifiers such as in U+1F634 sleeping face.
- Some current emoji were added for compatibility, and would not now qualify for emoji proposals because they include text or abstract symbols. These include U+1F195 NEW button or ♓️ U+2653 Pisces. See also Faulty
comparison.- It is a strong negative factor if a proposed
emoji is not distinct enough from existing emoji (or
sequences of emoji), either semantically or in appearance, or contains text or abstract symbols.
Completeness. Does
the proposed pictograph fill a gap in existing types of
emoji?
- In Unicode 8.0, for example, five emoji were added
to complete the zodiac, including
SCORPION.
- This factor has a small weight, compared to other
countervailing factors, especially low expected frequency. Mark this as n/a unless there are compelling examples.- The goal is iconic representation of large
categories, not completeness in the sense of filling
out the categories of a scientific or taxonomic
classification system.
- Proposals should not attempt to make distinctions
that are too narrow. For example, there are emoji for
hearts typically drawn as purple, blue, green, yellow,
red, …; there is no need for finer gradations of color,
like sienna.
Selection Factors for Exclusion
Before approving as candidates or adding to a release of
Petitions or “frequent requests”.
- Do not simply include listings of examples from social media of people calling for the emoji. That is not reliable enough data to be useful, and just detracts from the strength of your proposal.
- Similarly, petitions are counterproductive, and play
no role in selecting emoji. They are not considered as evidence, since they are too easily
skewed:
- Petitions may have duplicates or robovotes.
- The results could be skewed by commercial
or special-interest promotion of the petition.- For example, the
commercial petitions forTACO played no part in its selection; the TACO was approved based on evidence in its proposal, not the petitions.
Overly
specific. Is the
proposed character overly specific?
- For example,
SUSHI represents sushi in general, although images
frequently show a specific type, such as Maguro. Adding
SABA, HAMACHI, SAKE, AMAEBI and others would be overly
specific.
- A limited number of emoji can be
added each year. Thus emoji that “break new ground” are
strongly favored over emoji that are variants of others.
Thus a proposal for additional species of owl would be
viewed negatively.
Open-ended. Is it
just one of many, with no special reason to favor it over
others of that type?
Already
representable. Can the concept be represented by
another emoji or sequence, even
if the image is not exactly the same?
- For example, a crying baby can already be
represented by
CRYING FACE + BABY; a
squirrel is already often represented by the chipmunk
emoji.
- A building associated with a particular religion
might be represented by a
PLACE OF WORSHIP emoji followed by a one of the many
religious symbols in Unicode.
- Halloween could be represented by either just
JACK-O-LANTERN, or a sequence of
JACK-O-LANTERN + GHOST.
Note: An image combining two or
more other emoji can be represented by an emoji
zwj sequence. See examples. Such
images are already representable, and do not have to be
approved by the Unicode Consortium. They can be requested of
vendors.
Logos, brands, UI
icons, signage, specific people, specific landmarks, deities. Are the
images unsuitable for encoding as characters?
- Images such as company logos, or those showing
company brands as part or all of the image, or images of
products strongly associated with a particular brand.- UI icons such as Material
Design Icons, Winjs
Icons, or Font
Awesome Icons, which are often discarded or modified to
meet evolving UI needs
- Signage such as
. See
also Slate’s The
Big Red Word vs. the Little Green Man
- Note that symbols used in signage or user
interfaces may be encoded in Unicode for reasons
unconnected with their use as emoji.- Specific people, whether fictional, historic, or living
- Specific buildings or other locations, whether fictional, historic, or modern
- Deities
Transient.
Is the expected level of usage likely to continue into the
future, or would it just be a fad?
- Transient or faddish symbols are poor candidates for
encoding.
Faulty
comparison. Are proposals being justified primarily
by being similar to (or more important than) existing
compatibility emoji?
- Many emoji were added only for compatibility, and
would not have been added otherwise. Their
existence does not justify proposals for emoji like them.
For example:
- The emoji
does not justify adding an emoji for ‘OLD’, or an emoji for
‘NEU’ (German). The same is true of the ideographic characters, such as .- The emoji { } do not justify additional front vs
full-body views of the same animal- The emoji { } or { } do not justify adding
different varieties of the same kind of animal- Four different mailboxes { } do not
justify adding your favorite “more important than a
mailbox” emoji.- The Tokyo Tower (a specific building) does not justify adding the Eiffel Tower.
Exact Images. Does the proposal request an exact image?
- Emoji are by their nature subject to variation in order to have consistent graphic designs for a full set. Precise images (such as from a specific visual meme) are not appropriate as emoji; images such as GIFs or PNGs should be used in such cases, instead of emoji characters.
- Once an emoji is released, it is typically used for a wide variety of items that have similar visual appearance.
Region Flags Without Code. Flags intended to represent specific countries or regions of the world must have a valid Unicode region code (based on ISO/BCP47) or Unicode subdivision code (based on ISO 3166-2).
- Flags are subject to special criteria
which vary by flag type.
Unicode, other considerations are taken into account. See UTC Consideration.
Evidence
The goal of this section of your proposal is to gather
of Frequency
information that can be used to assess the expected usage
level for the new emoji. There is no perfect way to do this,
but you are expected to supply the following data to help the
committee assess your proposal.
Please read this section and follow all the instructions; otherwise your proposal will likely be rejected.
You can, in addition, supply data using another
All data needs to be publicly available and
reproducible. Of course, search results may vary over time,
so the data you provide will be a snapshot at a particular
time. The reproducibility must be quick: it cannot require
more than a few minutes to reproduce the data you supply.
You need to supply screenshots of each result for each of the methods listed below: Google Search, Bing Search, Google
Video Search, Google Trends (Web Search), and Google Trends (Image Search).
process that can be used to help establish expected usage
levels. However, you must substantiate why your method is reproducible, and comparable in quality. For example, it is a waste of time to supply a list of
1,000 data points gathered on Twitter over a month containing
“emu”. First, that is not reproducible without
considerable effort, and second, it is useless without
comparable data for an existing emoji like
“elephant”. Please contact us if you have other suggestions for other
ways to get pertinent frequency data about expected emoji
usage, before you spend time collecting data.
Proposed smiley faces need to be assessed differently, since
comparisons are quite difficult. Generally the best terms capture
the particular gesture, expression, or emotion, but proposals must
be careful to provide evidence that (a) such emotions or expressions
cannot be conveyed by the existing smileys, and that (b) there is a
very strong association between the suggested image and the search
terms. A good example would be the drooling face emoji,
and the search term "drooling".
Flags
Proposals for flags are subject to special criteria.
- Country flags are only valid for countries with
Unicode region codes (based on ISO/BCP47). These are added automatically, and do not require proposals.- Country subdivision (states, provinces) flags are valid already for all
Unicode subdivision codes (based on ISO 3166-2). Only a handful out of the five thousand or so subdivisions have RGI emoji.
- Adding further subdivision flags as RGI can appear to play favorites unless similar subdivisions also get flags, which could mean “all other flags of that country” or “all subdivisions of greater or equal population in other countries”
- The frequency of usage for flags tends to be quite low for all but the most prominent, so the committee is not making recommendations until there are better means of assessing the likely frequency of usage. Proposals to add subdivision flags as RGI are brought to the attention of vendors at quarterly UTC meetings.
- No mechanism currently exists within the Unicode Standard to support flags for regions of the world which do not have a valid Unicode region code (based on ISO/BCP47) or Unicode subdivision code (based on ISO 3166-2). This includes historical flags (for example: South Vietnam) as well as current flags which do not have a corresponding region code or subdivision code (for example: Assyrian, Australian Aboriginal, Kurdistan, Maori, Torres Strait Islander).
- Other flags (not representing countries, regions, or geopolitical bodies) may be considered for representation as emoji. These are subject to regular Unicode emoji selection factors, such as expected usage, and so on.
Reducing irrelevant results
Reasonable efforts need to be made to remove irrelevant
results. In the following, a search phrase (what you would type in the search box) is presented in [square brackets].
Minimize search
personalization. Do all of your searches in an “private”
browser window where possible, to help remove the effects of search
personalization. Private browser windows are opened with menus like the following, depending on the browser: New Private Window, New Incognito Window, InPrivate Window.
Supply a category term also. When you search for
[mammoth] alone, for example, you may get many
irrelevant results, such as “Mammoth Mountain” (a
ski resort) or “Mammoth Motocross” (a sports
event), etc.
- In such cases, your searches need to be qualified by a category term, such as [mammoth animal]. A term like “fly” can be even
worse, because of the use as a verb (see below): [fly insect]
can pick up items that are not about “flies” but
rather other insects that fly. The category terms for each
item don't have to be identical, as long as they provide the
appropriate filtering. For an example with "bird" and
"animal", see below. For Google Trends, you would use a qualifying category.
Group multiword terms. Searches with spaces are a problem, since [fish eye] would match pages with the word "fish" in the last paragraph and "eye" in the first. To help account for this, never have spaces within a search term or category: use hyphens instead. For example, when searching for black swan, use [black-swan]. Otherwise the search data you supply will likely be rejected (without the hyphen there could be a hit on a page with “black” in the first paragraph and “swan” in the last). For example, use:
Complex cases. If a term has multiple meanings that are not excluded by a category term, list those meanings in your proposal (ideally include a snapshot like https://www.dictionary.com/browse/seal or https://www.merriam-webster.com/dictionary/seal. Then use additional techniques to address that, using OR for alternate terms, and/or - for excluding terms. For example, [notebook -computer] or [knockbox OR bash-bin]. See Refine web searches for more details.
Choose your language. If your proposed emoji has high usage in a broad
region of the world but relatively low usage in English,
please also supply the equivalent searches in the
appropriate language(s) of that region. Use languages that
have the largest literate populations in that region to allow
comparison; and please supply the translations from English.
- That can also be helpful in avoiding irrelevant
results in English (such as for “fly”).Required Information
The following information is required. For comparison, the median values for median-use emoji are currently:
B.1.a Google Search 500M B.1.b Bing Search 25M B.1.c
Google Video Search75M B.1.d Google Trends: Web Search comparable to elephant
B.1.e Google Trends: Image Search comparable to elephant
However, the values are factors that are taken into consideration, not hard limits.
B.1.a Google Search
https://www.google.com/search?q=swan
B.1.b Bing Search
https://www.bing.com/search?q=swan
https://www.google.com/search?tbm=vid&q=swan
B.1.c Google Video Search
B.1.d Google Trends: Web Search
https://trends.google.com/trends/explore?date=all&q=elephant,swan
For this tool, you must also include a search for your proposed emoji plus a comparison value, and select a category. Use elephant as the comparison.
For this and other tools that let you set start/end
dates, use the longest possible range.
B.1.e Google Trends: Image Search
Do the same as for Google Trends: Web Search, but pick
Image Search.
https://trends.google.com/trends/explore?date=all_2008&gprop=images&q=elephant,swan
Process and Timeline
The following describes the process and approximate
timeline for new emoji characters.
Initial
Proposal
- Submitter reviews Submitting
a Proposal (especially the examples), and writes up a
proposal.
- Proposals for new emoji characters must be submitted before March 31 of each year to be considered for inclusion in the release of the Unicode Standard for the following year.
- Proposals for emojification and sequences must be submitted before Sept 1 of each year to be considered for inclusion in the release of the Unicode Standard for the following year.
- Proposals are normally processed in the order in which they arrive. Proposals should be submitted as early as possible, however, to allow time for modifications as described below. Submission by the deadline does not guarantee that a proposal will be considered in time for the following year, if too many proposals are received at once.
- The proposal is submitted to the Unicode Consortium
and then referred to the Emoji subcommittee, which meets weekly
by phone. However, there is typically a very full agenda, and
it can take up to 30 days (and sometimes longer) for the
initial review of a new proposal.
- Not every proposal will be forwarded to the UTC for
consideration. Some proposals that clearly do not meet the
selection criteria, such as proposals to add emoji characters
representing logos, specific persons, or deities, are
excluded, and the author is informed that the proposal is
declined.- Other proposals typically need improvements and
clarifications, so the author is informed of problems and
asked to make corrections.- Other proposals may be incorporated into a larger list
of related characters (such as Foods, or Sports) that is being
developed by the emoji subcommittee. Recommendations for
consideration of the top characters on these lists is
submitted to the UTC. (This is typically a small percentage of
each list.)- Once the proposal is well-formed, and has made a
reasonably strong case for a new emoji character, then the
emoji subcommittee submits it to the UTC. Not all well-formed proposals are forwarded to the UTC. Submission
of a proposal to the UTC does not mean that the proposal has
been recommended by the ESC. The submission is simply to
notify the UTC of a well-formed proposal.
For more information, see the Emoji Submission FAQ.UTC
Consideration
- The UTC has a quarterly
week-long meeting, typically held in the middle of each
quarter. Consideration of proposals to add emoji characters is
only a portion of the full UTC agenda for each meeting.
- Before each UTC meeting, the ESC produces a list of
the recommended proposals.- Proposals are discussed, and may be accepted as
candidates, or be declined, or returned for more work. Often
it takes more than one UTC meeting to get consensus.
- Compared to most other characters in Unicode, there
is greater public awareness of new emoji characters, and a
high expectation of support for them from major platform
vendors (such as Android, iOS, Windows, Twitter, and
Facebook). Support from major platform vendors is needed to
ensure wide distribution of the proposed emoji. Although
there is no specific numerical criterion for new emoji use,
the goal is usage on the order of millions of daily active
users for each new emoji, rather than merely thousands.- Thus in addition to the selection factors, before
approving a new emoji character the Unicode Technical
Committee needs to expect wide deployment: that major
vendors of emoji would plan to include the proposed
character into very widely deployed fonts and input methods
(keyboards / palettes / speech). Support for more than about
50–100 new emoji a year is problematic for vendors. The cost
and complexity to support new emoji characters is much
higher than for most other Unicode characters, especially on
devices with limited memory.- The committee balances the choices of emoji in a
given set of candidates or release. For example, rather than
15 different breeds of dogs, the committee might choose to
have some faces, some clothing, other animals, food items,
transport items, and sports.- Those proposals that are provisionally accepted by the
UTC as candidates are added as Provisional
Candidates, with placeholder code points such as X00002.
- At the Q2 UTC meeting each year, a decision is made
about which of the candidates to advance to Draft
Candidates for encoding in the following year’s Unicode
release. The candidate pool includes both the Provisional
Candidates and proposals processed by the ESC between the Q2
and Q3 UTC meetings.
- At the Q4 UTC meeting the subsequent year, a final
determination is made as to the emoji characters that are to
be in that year’s release. This list constitutes the Final
Candidates for the release.Processing
Final Candidates
- Code points are assigned to Final Candidates. The
emoji property values of the new characters are determined and
added to the beta property data files for the
next version of Emoji.
- Draft short names, keywords, and sort order are added
to the beta of the upcoming version of CLDR.
- The Unicode character properties of the characters are
specified and appear in the beta property data files for the
next release of the Unicode Standard.- Implementers have the opportunity to make sure that
those properties are correct, and will not cause problems.- After the review of the beta emoji properties is
finished, the UTC publishes the final repertoire and emoji
property values for that version of Unicode Emoji. This may
happen before a version of Unicode is published. Vendors can
then start the process of implementation: image design, fonts,
keyboards, parsing, segmentation, etc.- After the period for the beta review closes, the UTC
determines the final code points and properties, so that the
characters are ready for deployment.- The new emoji characters are published in a version of
Unicode. Once published, they are a
permanent part of the standard. Information about them is
added to Full
Emoji List.
- Unicode member companies may often start preparing
fonts, keyboards, and other supporting software for the new
emoji characters somewhat before the release, depending on
their release schedule.Sample
The following is a sample timeline for a typical
Timeline
successful proposal.
Normally proposals need to be submitted to the Emoji
Date Description Y1 Q1
A proposal for 5 emoji characters is submitted to
Unicode and referred to the Emoji subcommittee (ESC). The
proposal goes through three revisions, and is then accepted
by the Emoji subcommittee for forwarding to the UTC.Y1 Q2
The UTC adds 4 of the characters as Provisional
Candidates, declining one of the characters.
Y1 Q3
The UTC reviews the ESC’s overall prioritized list
for emoji for the next year, possibly making changes, and
makes 3 of these characters be Draft
Candidates.
Y1 Q4
CLDR begins translation of the Emoji names and
keywords, and determines a sort order.Y2 Q1
After further review, one of the characters is
removed. The rest are advanced to Final
Candidate status. The draft Unicode Character Properties
are completed for the remaining 2 emoji characters, and
included in the beta of Unicode version X. CLDR removes the
declined characters, and finalizes the names, keywords, and
sort order. Vendors begin design.
Y2 Q2
The 2 approved characters are published in Unicode
version X at the end of the quarter, and are included in the
final data files.Y2 Q2+
Vendors begin to support the 2 new characters.
subcommittee at least a year before they can appear in a
Unicode release.
Process
for Proposed Emoji Sequences
The process is simpler for emoji sequences and other
proposals that don't require new characters.
- If the proposal is not well-formed, the emoji
subcommittee responds to the proposer with suggestions for
fixing, as is done for new emoji character proposals.- Once a proposal is well-formed, the emoji subcommittee may submit the proposal to the UTC to bring it to the attention of vendors. However, not all well-formed proposals are forwarded to the UTC. For more information, see the Emoji Submission FAQ.
For proposals to make valid sequences be RGI:
The emoji subcommittee prepares a summary document for
consideration by major vendors.
For proposals to add tag sequences or change
emoji properties (such as to make an existing character be
emoji): The UTC decides whether or not to change the next
version of UTR
#51, Unicode Emoji and/or associated emoji data.
Last updated:
- 8/20/2019, 11:37:22 AM
- Contact Us
