But today, where emoji are parsed correctly, that's not a couple of pointless empty squares but a POP followed by an ignored FE0E, which is exactly my expectations accordingly with today standards.
If tomorrow this would change form some reason, it's not a problem of today parsers and unless you intentionally create that sequence for your own purposes, no keyboard would automatically put such sequence in a text field since such sequence as it is is meaningless for today standards. All good then, I've got my parser right :-) THanks On Sun, Jun 29, 2014 at 1:51 AM, Richard Wordingham < richard.wording...@ntlworld.com> wrote: > On Sat, 28 Jun 2014 10:33:17 -0700 > Andrea Giammarchi <andrea.giammar...@gmail.com> wrote: > > > I am trying to understand the expected behavior when there an > > "unexpected VS15" after emoji that have not been defined, accordingly > > with this file http://www.unicode.org/Public/UNIDATA/NamesList.txt, > > as VS15 sensitive. > > Variation selectors are 'default ignorable' - if an implementation > does not understand it, it should ignore it. In particular, > Section 16.4 Version 6.3.0 of the Unicode Standard says that if the > application does not understand the combination of base character and > variation selector the variation selector should normally be ignored. > This does not preclude the possibility that the renderer only has > special modes, in all of which unknown variation selectors are displayed > as flashing red question marks. > > > My take on FE0E is that all emoji that are sensible to this variant, > > have an "emojified" counter part that should be used when followed by > > FE0F and vice-versa a textual part when followed by FE0E, but all > > other emoji should not consider such variant at all since there's no > > textual counter part to represent, let's say, a 1F21A pile-of-poo > > > > "\ud83d\udca9\ufe0e" > > > > Can anyone please confirm my expectations are correct so that above > > sequence in both Java or JavaScript will show the POP emoji > > regardless, followed by FE0E variant that will be simply ignored and > > actually no device/OS/render/viewer/browser would ever create such > > sequence so it's actually a non problem, this one I am trying to > > solve? > > There was nothing to stop me putting the sequence "đŠī¸" <U+1F4A9 PILE > OF POO, U+FE0E VARIATION SELECTOR-15> in my reply. Moreover, there is > nothing to stop the sequence becoming defined at some time in the > future. > > Richard. > > _______________________________________________ > Unicode mailing list > Unicode@unicode.org > http://unicode.org/mailman/listinfo/unicode >
_______________________________________________ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
