Additional Emoji selection factor: Support by "Major Vendors"

Philippe Verdy verdy_p at
Sun Sep 11 09:21:27 CDT 2016

2016-09-11 14:40 GMT+02:00 Christoph Päper <christoph.paeper at>:

> Mark Davis ☕️ <mark at>:
> >
> > I haven’t been able to find out what constitutes a “major vendor”.
> Apple, Microsoft and Google are certainly ones (and Unicode Full Members),
> but what about, for instance, Samsung, LG, Sony,

They are vendors yes, but for hardware devices using common platforms
(Windows and Android most often, or derived directly from Android). The
hardware capabilities of devices made by them are mostly the same as the
ycompete at the same time on the same global market with similar features.

The good question however is how they support these devices for the long
term: sales of new mobile devices are slowing down, as more and more people
feel that they are too much expensive and there's now a life to maintain
devices functional, and there's now a vivid secondary market for repairing
or upgrading them, or changing their batteries instead of buying a new
device (additionally now people already have a secondary phone, possibly
older, but that can be used as backup when necessary).

> Twitter/Twemoji, Facebook, Whatsapp or widely-used platform-independent
> ones like Emojione (mostly Associate Members or not Unicode members at all)?

These are connected wep apps, and web apps have no difficulties to support
and upgrade their supporting fonts or collections of icons. Users don't
need to upgrade, this occurs almost transparently. If these are mobile
apps, they are updated extremely frequently from their publication store
(Windows Store, Google Play, Apple Store), using simple procedures (however
mobile apps tend to grow in size at each update, forcing users to select
which one they'll keep, or forcing them to uninstall one to install another
one, then switch back, if they have old models with low storage capacity:
8GB smartphones are now deprecating in factor of 16GB ones, but these app
vendors should propose several versions of their apps for users with
limited storage, and they forget to monitor the market to see that this
growth of app sizes is becoming a problem, when many features are added but
not used by users. Most resident features should better be installed on
demand in a cache that will clean up automatically if storage becomes too
low; ideally most apps should be online and should use minimal local code).

Beside these vendors, there remain some niche markets for mobile devices
that have their own OS not compatible and not supported by these wellknown
apps vendors. But most of them are created based on a Linux core (just like
Android itself), and use wellknown platforms (Java, .Net, or simply the
HTML/CSS support of the builtin browser) and apps are not complicate to

The real complication is in the default support for input interfaces (i.e.
virtual keyboards) that these apps need, and adaptaing them for the local
markets (languages). Emoji input however is mostly independant and can be
developped and supported across languages in the same input panels.

The necessary sets of fonts or icons may also be instaleld transparently
using web queries and the standard browser cache. These should be mostly
independant of the target app platform or OS. vendors may develop their own
common subsets (with personalized style), but there will be plenty of
alternative offers (just like there's a lot of providers since long for
emoticons, long before many of them where encoded). I don't think this is a
major problem.

However the complexity now is not in the encoding of emojis but the recent
development of complex encodings requiring now large ligature tables to
work properly, and/or using variant selectors. The most common combinations
should be better documented in the standard (it is possible to encode them
in the list of "named sequences", or in a separate list specifically for
emojis). But I wonder if this is productive to show all styles for emojis:
why not returning to just display a single representative glyph, with basic
"flat" designs, but probably with some colors to help distinguishing them:
but which version from which vendor should the standard use for that glyph

Emoji doc pages and reports in the Unicode site tend to become very large
and it becomes much harder now to initiale new sets for designing new
styles. Google, Apple, Microsoft, Facebook can develop their own sets, just
like there are standard sets from Japanese telcos.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Unicode mailing list