That was the point. As the section actually doesn't work as a normative standard as you said, I didn't know how to describe why Android OS and iOS have the different default settings (I'm in preparation of Android tech presentation in next month.) (cont.)
-
-
During investigation the only clue to the mystery was the commit log. After all, according to your answer the conclusion is that there is no obvious standard in industry, however your answer should be the part of the convincing explanation of this situation.
1 reply 0 retweets 0 likes -
Replying to @tacke_jp @raphlinus
There's also a lot of work done by
@FakeUnicode figuring out what Twitter (as well as other platforms?) does with the choice of emoji or text presentation. I assume they'll point you to it.1 reply 0 retweets 1 like -
Fake “Unicode.” ↙️ Retweeted Fake “Unicode.” ↙️
Twitter follows the guidelines at http://unicode.org/emoji/charts/text-style.html … but with a few exceptions: Everything -EP is +EP except ©®™ (because they are ugly) and ♟ (because of existing twitter chess games). +EP +EPSq 2010 dings are treated -EPSq (no text variant)https://twitter.com/FakeUnicode/status/1054878183722430464 …
Fake “Unicode.” ↙️ added,
1 reply 0 retweets 4 likes -
Replying to @FakeUnicode @roozbehp and
Fake “Unicode.” ↙️ Retweeted Bryan 🏠 Haggerty
The reasons for mostly ignoring -EP are historical/presentational, and sometimes debated for new additions. EG:https://twitter.com/bhaggs/status/966061521838092288 …
Fake “Unicode.” ↙️ added,
1 reply 0 retweets 3 likes -
Replying to @FakeUnicode @roozbehp and
Fake “Unicode.” ↙️ Retweeted Tom Wuttke 🍇
The ©®™ honoring -EP exception was purely aesthetic: https://twitter.com/tw/status/705825127401783296 … Much later they added support for ©®™ + VS-16 for them.
Fake “Unicode.” ↙️ added,
1 reply 0 retweets 3 likes -
Replying to @FakeUnicode @roozbehp and
We've only mostly done presentation research of Twitter. Though Samsung's deviations are legendary. 82 of the 256 glyphs in https://en.wikipedia.org/wiki/Miscellaneous_Symbols … are emoji, but Samsung just emojified them *all*.pic.twitter.com/jXjV7hRSPq
1 reply 0 retweets 3 likes -
Replying to @FakeUnicode @roozbehp and
Also see
@CharlotteBuff@Informoji@EmojiInformer1 reply 0 retweets 1 like -
Replying to @FakeUnicode @roozbehp and
What I'm taking away from this conversation is that all the emoji presentation weirdness on Android is deliberate?
1 reply 0 retweets 0 likes -
Replying to @CharlotteBuff @FakeUnicode and
Was partially deliberate (based on font availability at the time: we didn't have B&W fonts for some characters). No idea if it's deliberate anymore, since
@raphlinus and I left Android.1 reply 0 retweets 1 like
Deliberate in the sense of trying to make the best compromise for users, which I think we did. It's also a mess, but I would call that a missed opportunity for Unicode to specify behavior.
-
-
Replying to @raphlinus @roozbehp and
Unicode does specify behaviour, though. It just isn't implemented correctly on any of the platforms I've seen. Even Chrome on Windows treats some text-default characters as emoji-default for no reason.
1 reply 0 retweets 0 likes -
Replying to @CharlotteBuff @roozbehp and
It specifies behavior too weakly to be useful. This is largely because implementations got ahead of the spec. And now it's too late to fix other than declare that you need to use VS if you expect consistent rendering.
0 replies 0 retweets 2 likes
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
︎
︎
︎
︎
Though the +EP +EPSq 2009s work: ⛪︎⛲︎⛺︎⛽︎⛵︎⛅︎⛄︎⚽︎⚾︎⛔︎⭕︎❗︎🈯︎
And the 2010 -EP +EPSq ⏭︎⏮︎
It is probably because they were in the first emoji batch ¯\_(ツ)_/¯

don't emojify on