Additional Emoji selection factor: Support by "Major Vendors"

[Christoph Päper]

Philippe Verdy <verdy_p at wanadoo.fr>:
> 2016-09-11 14:40 GMT+02:00 Christoph Päper <christoph.paeper at crissov.de>:
> 
>> I haven’t been able to find out what constitutes a “major vendor”. Apple, Microsoft and Google are certainly ones (…), but what about, for instance, Samsung, LG, Sony,
> 
> They are vendors yes, but for hardware devices using common platforms (…).

The important point here is that at least Samsung and LG are selling millions of devices annually with custom emoji fonts installed on them.

> The good question however is how they support these devices for the long term:

Many vendors are indeed really, really bad at developing, maintaining and rolling out OS updates for much of their product line-up. Even Apple supports their iOS devices for only ca. 5 years (from launch, not purchase)^, although the update infrastructure is already set up and new fonts by themselves would be rather small and simple fixes. Current emoji font files for mobile operating systems are somewhere between 3 MB (vector-based) and almost 40 MB (bitmap-based). 

^ Apple released iOS 5, the first version with non-PUA emojis and iMessages (IIRC), and the iPhone 4s in late 2011. The OS update being deployed this week (i.e. iOS 10) will no longer support that device which was sold in some places until earlier this year. That means, there are now iOS devices which were capable of handling Unicode emojis at their launch date, but will be permanently incapable of displaying new ones from Unicode 9 or later.

>> Twitter/Twemoji, Facebook, Whatsapp or widely-used platform-independent ones like Emojione (…)?
> 
> 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

That’s quite true, but doesn’t say anything about whether they’re “major vendors” when it comes standardizing new emoji characters in Unicode.

> 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.

That’s a general assumption, but I’m not sure it would hold against a user test. Observe, for instance, how on 11 September (or 4 July or during the Olympics) people complain on Twitter and elsewhere that they cannot find their “American flag emoji” on the top of the list, or how they confuse it with the Liberian or Malaysian regional indicator (cf. Texas vs. Chile). That’s why there are customized panels for frequently or recently used emojis, or auto-replace and suggest-as-you-type algorithms.

> 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.

Those large tables can be generated by rather short algorithms, which perhaps could be simpler if emoji properties were more systematic.