Re: Feedback on the proposal to change U+FFFD generation when decoding ill-formed UTF-8

[Alastair Houghton via Unicode]

On 18 May 2017, at 01:04, Philippe Verdy via Unicode  
wrote:
> 
> I find intriguating that the update intends to enforce the decoding of the 
> **shortest** sequences, but now wants to treat **maximal sequences** as a 
> single unit with arbitrary length. UTF-8 was designed to work only with some 
> state machines that would NEVER need to parse more than 4 bytes.

This won’t change.  You still don’t need to parse more than four bytes.  In 
fact, you don’t need to do *anything*, even if your implementation doesn’t 
match the proposal, because *it’s only a recommendation*.  But if you did 
choose to do something, you *still* don’t need to scan arbitrary numbers of 
bytes.

> For me, as soon as the first byte encountered is invalid, the current 
> sequence should be stopped there and treated as error (replaced by U+FFFD is 
> replacement is enabled instead of returning an error or throwing an 
> exception),

This is still essentially true under the proposal; the only difference is that 
instead of being a clever dick and taking account of the valid *code point* 
ranges while doing this in order to ban certain trailing bytes given the values 
of their predecessors, you allow any trailing byte, and only worry about 
whether the complete sequence represents a valid code point or is over-long 
once you’ve finished reading it.  You never need to read more than four bytes 
under the new proposal, because the lead byte tells you how many to expect, and 
you’d still stop and instantly replace with U+FFFD if you see a byte outside 
the 0x80-0xbf range, even if you hadn’t scanned the number of bytes the lead 
byte says to expect.

This also *does not* change the view of the underlying UTF-8 string based on 
iteration direction; you would still generate the exact same sequence of code 
points in both directions.

Kind regards,

Alastair.

--
http://alastairs-place.net

Re: Feedback on the proposal to change U+FFFD generation when decoding ill-formed UTF-8

[Alastair Houghton via Unicode]

On 18 May 2017, at 06:01, Richard Wordingham via Unicode  
wrote:
> 
> On Thu, 18 May 2017 02:04:55 +0200
> Philippe Verdy via Unicode  wrote:
> 
>> I find intriguating that the update intends to enforce the decoding
>> of the **shortest** sequences, but now wants to treat **maximal
>> sequences** as a single unit with arbitrary length. UTF-8 was
>> designed to work only with some state machines that would NEVER need
>> to parse more than 4 bytes.
> 
> If you look at the sample code in
> http://www.unicode.org/versions/Unicode2.0.0/appA.pdf, you'll see that
> it's working with 6-byte sequences.  It's the Unicode, as opposed to
> ISO 10646, version that has always been restricted to 4 bytes.

There are good reasons for restricting it to four byte sequences, mind; doing 
so increases the number of invalid code units, which makes it easier to detect 
UTF-8 versus not UTF-8.  I don’t think anyone is proposing allowing 5-byte or 
6-byte sequences.

Kind regards,

Alastair.

--
http://alastairs-place.net

Re: Feedback on the proposal to change U+FFFD generation when decoding ill-formed UTF-8

[Hans Åberg via Unicode]

> On 16 May 2017, at 15:21, Richard Wordingham via Unicode 
>  wrote:
> 
> On Tue, 16 May 2017 14:44:44 +0200
> Hans Åberg via Unicode  wrote:
> 
>>> On 15 May 2017, at 12:21, Henri Sivonen via Unicode
>>>  wrote:  
>> ...
>>> I think Unicode should not adopt the proposed change.  
>> 
>> It would be useful, for use with filesystems, to have Unicode
>> codepoint markers that indicate how UTF-8, including non-valid
>> sequences, is translated into UTF-32 in a way that the original octet
>> sequence can be restored.
> 
> Escape sequences for the inappropriate bytes is the natural technique.
> Your problem is smoothly transitioning so that the escape character is
> always escaped when it means itself. Strictly, it can't be done.
> 
> Of course, some sequences of escaped characters should be prohibited.
> Checking could be fiddly.

One could write the bytes using \xnn escape codes, sequences terminated using 
\& as in Haskell, translating '\' into "\\". It then becomes a C-encoded 
string, not plain text.

Re: Feedback on the proposal to change U+FFFD generation when decoding ill-formed UTF-8

[Alastair Houghton via Unicode]

On 18 May 2017, at 07:18, Henri Sivonen via Unicode  wrote:
> 
> the decision complicates U+FFFD generation when validating UTF-8 by state 
> machine.

It *really* doesn’t.  Even if you’re hell bent on using a pure state machine 
approach, you need to add maybe two additional error states 
(two-trailing-bytes-to-eat-then-fffd and one-trailing-byte-to-eat-then-fffd) on 
top of the states you already have.  The implementation complexity argument is 
a *total* red herring.

> 2) Procedural: To be considered in the future, proposals to change
> what the standard suggests or requires implementations to do should
> consider different implementation strategies and discuss the impact of
> the change in the light of the different implementation strategies (in
> the matter at hand, I think the proposal should have included a
> discussion of the impact on UTF-8 validation state machines)

Well, let’s discuss that here and now (see above).  Do you, for some reason, 
think that it’s more complicated than I suggest?

Kind regards,

Alastair.

--
http://alastairs-place.net

Petition to ban Google from designing emoji

[zelpa via Unicode]

http://blog.emojipedia.org/rip-blobs-google-redesigns-emojis/

Is this some kind of joke? Have Google put ANY thought into their emoji
design? First they bastardise the cute blob emoji, then they make their
emoji gendered, now they've literally just copied Apple's emoji. It's
sickening. Disgusting. I propose we hold a petition for the Unicode
Consortium to ban Google from designing emoji in the future, and make them
revert back to the Android 5 designs. Everyone in favour of this please
leave a response, anybody not in favour please rethink your opinion.

Re: Petition to ban Google from designing emoji

[David Faulks via Unicode]

And what makes you think Unicode has any authority to ‘ban’ Google from doing 
anything at all (hint: Unicode has zero ability to enforce anything).


On Thu, 5/18/17, zelpa via Unicode  wrote:

 Subject: Petition to ban Google from designing emoji
 To: "Unicode Public" 
 Received: Thursday, May 18, 2017, 7:40 AM
 
 http://blog.emojipedia.org/rip-blobs-google-redesigns-emojis/
 
 Is this some kind of joke? Have Google put ANY thought
 into their emoji design? First they bastardise the cute blob
 emoji, then they make their emoji gendered, now they've
 literally just copied Apple's emoji. It's sickening.
 Disgusting. I propose we hold a petition for the Unicode
 Consortium to ban Google from designing emoji in the future,
 and make them revert back to the Android 5 designs. Everyone
 in favour of this please leave a response, anybody not in
 favour please rethink your opinion.
 

Re: Petition to ban Google from designing emoji

[Rebecca T via Unicode]

Well, you’re certainly not alone in your distaste for the new design. @eevee
just today said “cool how we improved gender diversity by slowly changing

from ‘ambiguous/neutral’ to ‘explicit color-coded binary, default usually

male’” 

On the other hand, quoting @zaccolley: “if you treat emoji like pictures:

yay blobs, if you treat emoji like language: yay consistency”


Ultimately, the new emoji designs will make our digital communication less
ambiguous — I’m just not sure if that’s a good change or not, and I
certainly don’t enjoy Apple being the default (on principle and for their
designs specifically).

Quoting UTR #51: “General-purpose emoji for people and body parts should
also not be given overly specific images: the general recommendation is to
be as neutral as possible regarding race, ethnicity, and gender.”

Unambiguously, Apple has failed to meet these technical guidelines,
in a blatant and unapologetic manner, and that’s why I liked the blobs —
they bucked norms, refused to conform to trends, and made emoji more
friendly to people who didn’t want to attach a gender to their every
expression. I think that’s valuable and I’m sad to see it go.

And a serious response to this joke letter: Given that Google pays $18,000 /
annum to vote on new emoji, it seems unlikely that the Consortium will just
kick them out.


On Thu, May 18, 2017 at 7:40 AM, zelpa via Unicode 
wrote:

> http://blog.emojipedia.org/rip-blobs-google-redesigns-emojis/
>
> Is this some kind of joke? Have Google put ANY thought into their emoji
> design? First they bastardise the cute blob emoji, then they make their
> emoji gendered, now they've literally just copied Apple's emoji. It's
> sickening. Disgusting. I propose we hold a petition for the Unicode
> Consortium to ban Google from designing emoji in the future, and make them
> revert back to the Android 5 designs. Everyone in favour of this please
> leave a response, anybody not in favour please rethink your opinion.
>

Re: Petition to ban Google from designing emoji

[zelpa via Unicode]

>Unambiguously, Apple has failed to meet these technical guidelines,
>in a blatant and unapologetic manner, and that’s why I liked the blobs —
>they bucked norms, refused to conform to trends, and made emoji more
>friendly to people who didn’t want to attach a gender to their every
>expression. I think that’s valuable and I’m sad to see it go.

At least someone realised it was a (half) joke. This is my real issue,
Apple disregards guidelines, sets a de facto standard, Google races to copy
them. It's actually sad to see how far other vendors will go to copy
Apple's designs. I honestly think the consortium should try harder to
enforce the guidelines instead of letting Apple be the ruler and expecting
others to obey.

On Fri, May 19, 2017 at 12:07 AM, Rebecca T <637...@gmail.com> wrote:

> Well, you’re certainly not alone in your distaste for the new design.
> @eevee
> just today said “cool how we improved gender diversity by slowly changing
> 
> from ‘ambiguous/neutral’ to ‘explicit color-coded binary, default usually
> 
> male’” 
>
> On the other hand, quoting @zaccolley: “if you treat emoji like pictures:
> 
> yay blobs, if you treat emoji like language: yay consistency”
> 
>
> Ultimately, the new emoji designs will make our digital communication less
> ambiguous — I’m just not sure if that’s a good change or not, and I
> certainly don’t enjoy Apple being the default (on principle and for their
> designs specifically).
>
> Quoting UTR #51: “General-purpose emoji for people and body parts should
> also not be given overly specific images: the general recommendation is to
> be as neutral as possible regarding race, ethnicity, and gender.”
>
> Unambiguously, Apple has failed to meet these technical guidelines,
> in a blatant and unapologetic manner, and that’s why I liked the blobs —
> they bucked norms, refused to conform to trends, and made emoji more
> friendly to people who didn’t want to attach a gender to their every
> expression. I think that’s valuable and I’m sad to see it go.
>
> And a serious response to this joke letter: Given that Google pays $18,000
> /
> annum to vote on new emoji, it seems unlikely that the Consortium will just
> kick them out.
>
>
> On Thu, May 18, 2017 at 7:40 AM, zelpa via Unicode 
> wrote:
>
>> http://blog.emojipedia.org/rip-blobs-google-redesigns-emojis/
>>
>> Is this some kind of joke? Have Google put ANY thought into their emoji
>> design? First they bastardise the cute blob emoji, then they make their
>> emoji gendered, now they've literally just copied Apple's emoji. It's
>> sickening. Disgusting. I propose we hold a petition for the Unicode
>> Consortium to ban Google from designing emoji in the future, and make them
>> revert back to the Android 5 designs. Everyone in favour of this please
>> leave a response, anybody not in favour please rethink your opinion.
>>
>
>

Re: Petition to ban Google from designing emoji

[Doug Ewell via Unicode]

zelpa wrote:

> This is my real issue, Apple disregards guidelines, sets a de facto
> standard, Google races to copy them. It's actually sad to see how far
> other vendors will go to copy Apple's designs. I honestly think the
> consortium should try harder to enforce the guidelines instead of
> letting Apple be the ruler and expecting others to obey.

Given that one co-chair of the Emoji Subcommittee is from Apple and the
other is from Google, you may wish to rethink your expectations about
all this.

--
Doug Ewell | Thornton, CO, US | ewellic.org

Re: Petition to ban Google from designing emoji

[Gabriel von Dehn via Unicode]

Hi,

the Unicode Consortium does not and cannot “ban” vendors from designing emojis 
the way they wish. Unicode merely gives recommendations on how the characters 
should be displayed. Think of the different designs on different platforms like 
different fonts you can use (because that is actually what they are): They all 
look slightly different and no one would hold a petition for the design of 
characters in a font to change.

As for the gendered Emojis, those are in the Unicode specification now: 
http://emojipedia.org/emoji-4.0/ 

If you do not like the upcoming Emoji design from Google (or anything about the 
upcoming version of Android), you can report to Google directly, but posting on 
this List won’t help.


> On 18 May 2017, at 14:40, zelpa via Unicode  wrote:
> 
> http://blog.emojipedia.org/rip-blobs-google-redesigns-emojis/ 
> 
> 
> Is this some kind of joke? Have Google put ANY thought into their emoji 
> design? First they bastardise the cute blob emoji, then they make their emoji 
> gendered, now they've literally just copied Apple's emoji. It's sickening. 
> Disgusting. I propose we hold a petition for the Unicode Consortium to ban 
> Google from designing emoji in the future, and make them revert back to the 
> Android 5 designs. Everyone in favour of this please leave a response, 
> anybody not in favour please rethink your opinion.

Re: Petition to ban Google from designing emoji

[Gabriel von Dehn via Unicode]

As said, Unicode does not and cannot enforce anything. Unicode sets the 
recommendation, but has no power whatsoever of enforcing every vendor to meet 
these recommendations, nor does it expect vendors to follow Apples designs.


> On 18 May 2017, at 17:26, zelpa via Unicode  wrote:
> 
> >Unambiguously, Apple has failed to meet these technical guidelines,
> >in a blatant and unapologetic manner, and that’s why I liked the blobs —
> >they bucked norms, refused to conform to trends, and made emoji more
> >friendly to people who didn’t want to attach a gender to their every
> >expression. I think that’s valuable and I’m sad to see it go.
> 
> At least someone realised it was a (half) joke. This is my real issue, Apple 
> disregards guidelines, sets a de facto standard, Google races to copy them. 
> It's actually sad to see how far other vendors will go to copy Apple's 
> designs. I honestly think the consortium should try harder to enforce the 
> guidelines instead of letting Apple be the ruler and expecting others to obey.
> 
> On Fri, May 19, 2017 at 12:07 AM, Rebecca T <637...@gmail.com 
> > wrote:
> Well, you’re certainly not alone in your distaste for the new design. @eevee
> just today said “cool how we improved gender diversity by slowly changing 
> 
> from ‘ambiguous/neutral’ to ‘explicit color-coded binary, default usually 
> 
> male’” 
> 
> On the other hand, quoting @zaccolley: “if you treat emoji like pictures: 
> 
> yay blobs, if you treat emoji like language: yay consistency” 
> 
> 
> Ultimately, the new emoji designs will make our digital communication less
> ambiguous — I’m just not sure if that’s a good change or not, and I
> certainly don’t enjoy Apple being the default (on principle and for their
> designs specifically).
> 
> Quoting UTR #51: “General-purpose emoji for people and body parts should
> also not be given overly specific images: the general recommendation is to
> be as neutral as possible regarding race, ethnicity, and gender.”
> 
> Unambiguously, Apple has failed to meet these technical guidelines,
> in a blatant and unapologetic manner, and that’s why I liked the blobs —
> they bucked norms, refused to conform to trends, and made emoji more
> friendly to people who didn’t want to attach a gender to their every
> expression. I think that’s valuable and I’m sad to see it go.
> 
> And a serious response to this joke letter: Given that Google pays $18,000 /
> annum to vote on new emoji, it seems unlikely that the Consortium will just
> kick them out.
> 
> 
> On Thu, May 18, 2017 at 7:40 AM, zelpa via Unicode  > wrote:
> http://blog.emojipedia.org/rip-blobs-google-redesigns-emojis/ 
> 
> 
> Is this some kind of joke? Have Google put ANY thought into their emoji 
> design? First they bastardise the cute blob emoji, then they make their emoji 
> gendered, now they've literally just copied Apple's emoji. It's sickening. 
> Disgusting. I propose we hold a petition for the Unicode Consortium to ban 
> Google from designing emoji in the future, and make them revert back to the 
> Android 5 designs. Everyone in favour of this please leave a response, 
> anybody not in favour please rethink your opinion.
> 
> 

Re: Petition to ban Google from designing emoji

[Asmus Freytag via Unicode]

On 5/18/2017 7:41 AM, Doug Ewell via Unicode wrote:

zelpa wrote:


This is my real issue, Apple disregards guidelines, sets a de facto
standard, Google races to copy them. It's actually sad to see how far
other vendors will go to copy Apple's designs. I honestly think the
consortium should try harder to enforce the guidelines instead of
letting Apple be the ruler and expecting others to obey.

Given that one co-chair of the Emoji Subcommittee is from Apple and the
other is from Google, you may wish to rethink your expectations about
all this.



I'd expect "zelpa" to feel validated by this info in their concern, 
wouldn't you?


A./

Re: Petition to ban Google from designing emoji

[Doug Ewell via Unicode]

Asmus Freytag wrote:

>> Given that one co-chair of the Emoji Subcommittee is from Apple and
>> the other is from Google, you may wish to rethink your expectations
>> about all this.
>
> I'd expect "zelpa" to feel validated by this info in their concern,
> wouldn't you?

Well, it's public information: http://www.unicode.org/emoji/

The more important point is the one others have been making: Unicode
does not and cannot attempt to dictate to any vendor how to design
glyphs, either for normal characters like A and Ω and 丱 or for emoji.

Unicode does insist that the glyph design not misrepresent the meaning
of the character, which I believe was Michael Everson's objection to
vendors implementing U+1F3B1 BILLIARDS as a lone 8-ball. It's not clear
to me that the Google redesign discussed here goes that far; this seems
more like objection on aesthetic grounds. 
 
--
Doug Ewell | Thornton, CO, US | ewellic.org

Re: Petition to ban Google from designing emoji

[Shakil Anwar via Unicode]

A more democratic solution is to allow the global public to both submit and
vote on emoji designs. Rather than allow a small number of (probably) north
american white males to dictate emojis in a 'colonial' process based on
their own world and personal view.
The Unicode consortium can vote to change the process and now the proposal
has been made it will speak volumes if Google, Apple etc. choose not to
democratise.
ICANN chose to democratise their processes ; so can Unicode.

On 18 May 2017 at 15:16, Gabriel von Dehn via Unicode 
wrote:

> Hi,
>
> the Unicode Consortium does not and cannot “ban” vendors from designing
> emojis the way they wish. Unicode merely gives recommendations on how the
> characters should be displayed. Think of the different designs on different
> platforms like different fonts you can use (because that is actually what
> they *are*): They all look slightly different and no one would hold a
> petition for the design of characters in a font to change.
>
> As for the gendered Emojis, those are in the Unicode specification now:
> http://emojipedia.org/emoji-4.0/
>
> If you do not like the upcoming Emoji design from Google (or anything
> about the upcoming version of Android), you can report to Google directly,
> but posting on this List won’t help.
>
>
> On 18 May 2017, at 14:40, zelpa via Unicode  wrote:
>
> http://blog.emojipedia.org/rip-blobs-google-redesigns-emojis/
>
> Is this some kind of joke? Have Google put ANY thought into their emoji
> design? First they bastardise the cute blob emoji, then they make their
> emoji gendered, now they've literally just copied Apple's emoji. It's
> sickening. Disgusting. I propose we hold a petition for the Unicode
> Consortium to ban Google from designing emoji in the future, and make them
> revert back to the Android 5 designs. Everyone in favour of this please
> leave a response, anybody not in favour please rethink your opinion.
>
>
>

Re: Petition to ban Google from designing emoji

[Asmus Freytag via Unicode]

On 5/18/2017 9:48 AM, Doug Ewell via Unicode wrote:

Asmus Freytag wrote:


Given that one co-chair of the Emoji Subcommittee is from Apple and
the other is from Google, you may wish to rethink your expectations
about all this.

I'd expect "zelpa" to feel validated by this info in their concern,
wouldn't you?

Well, it's public information: http://www.unicode.org/emoji/

The more important point is the one others have been making: Unicode
does not and cannot attempt to dictate to any vendor how to design
glyphs, either for normal characters like A and Ω and 丱 or for emoji.

Unicode does insist that the glyph design not misrepresent the meaning
of the character, which I believe was Michael Everson's objection to
vendors implementing U+1F3B1 BILLIARDS as a lone 8-ball. It's not clear
to me that the Google redesign discussed here goes that far; this seems
more like objection on aesthetic grounds.
  


While this is all true, it seems to miss the point behind the whole 
complaint.


Attempts to counter "tongue-in-cheek" complaints with literal facts 
aren't always effective. :)


A./

Re: Petition to ban Google from designing emoji

[Gabriel von Dehn via Unicode]

Again, Unicode is not intended to and cannot ban specific designs of characters 
including emoji. Unicode is responsible creating a list of characters that 
should be supported, with the goal of making textual communication online 
possible through a standardised encoding. Unicode is not responsible for 
designing these characters, that is up to the vendors to decide.
From Unicodes Website: "Unicode provides a unique number for every character, 
no matter what the platform, no matter what the program, no matter what the 
language.”; "The Unicode Consortium was founded to develop, extend and promote 
use of the Unicode Standard, which specifies the representation of text in 
modern software products and standards.” 
(http://www.unicode.org/standard/WhatIsUnicode.html)

If you wish that a certain vendor - like Google or Apple - democratise their 
process of designing characters you should make that clear to them. Posting on 
this list will do absolutely nothing.

—

> On 18 May 2017, at 19:53, Shakil Anwar via Unicode  
> wrote:
> 
> A more democratic solution is to allow the global public to both submit and 
> vote on emoji designs. Rather than allow a small number of (probably) north 
> american white males to dictate emojis in a 'colonial' process based on their 
> own world and personal view.
> The Unicode consortium can vote to change the process and now the proposal 
> has been made it will speak volumes if Google, Apple etc. choose not to 
> democratise.
> ICANN chose to democratise their processes ; so can Unicode.
> 
> On 18 May 2017 at 15:16, Gabriel von Dehn via Unicode  > wrote:
> Hi,
> 
> the Unicode Consortium does not and cannot “ban” vendors from designing 
> emojis the way they wish. Unicode merely gives recommendations on how the 
> characters should be displayed. Think of the different designs on different 
> platforms like different fonts you can use (because that is actually what 
> they are): They all look slightly different and no one would hold a petition 
> for the design of characters in a font to change.
> 
> As for the gendered Emojis, those are in the Unicode specification now: 
> http://emojipedia.org/emoji-4.0/ 
> 
> If you do not like the upcoming Emoji design from Google (or anything about 
> the upcoming version of Android), you can report to Google directly, but 
> posting on this List won’t help.
> 
> 
>> On 18 May 2017, at 14:40, zelpa via Unicode > > wrote:
>> 
>> http://blog.emojipedia.org/rip-blobs-google-redesigns-emojis/ 
>> 
>> 
>> Is this some kind of joke? Have Google put ANY thought into their emoji 
>> design? First they bastardise the cute blob emoji, then they make their 
>> emoji gendered, now they've literally just copied Apple's emoji. It's 
>> sickening. Disgusting. I propose we hold a petition for the Unicode 
>> Consortium to ban Google from designing emoji in the future, and make them 
>> revert back to the Android 5 designs. Everyone in favour of this please 
>> leave a response, anybody not in favour please rethink your opinion.
> 
> 

Re: Petition to ban Google from designing emoji

[David Faulks via Unicode]

You cannot always tell things like these are jokes, I have seen people argue seriously that Unicode should dictate or enforce emojis before.

Re: Feedback on the proposal to change U+FFFD generation when decoding ill-formed UTF-8

[Richard Wordingham via Unicode]

On Thu, 18 May 2017 09:58:43 +0100
Alastair Houghton via Unicode  wrote:

> On 18 May 2017, at 07:18, Henri Sivonen via Unicode
>  wrote:
> > 
> > the decision complicates U+FFFD generation when validating UTF-8 by
> > state machine.  
> 
> It *really* doesn’t.  Even if you’re hell bent on using a pure state
> machine approach, you need to add maybe two additional error states
> (two-trailing-bytes-to-eat-then-fffd and
> one-trailing-byte-to-eat-then-fffd) on top of the states you already
> have.  The implementation complexity argument is a *total* red
> herring.

For big programs, yes.  However, for a small program it can be
attractive to have a small hand-coded routine so that the source code
can sit in a single file.  It can even allow a basically UTF-8 program
to meet a requirement to be able to match lone surrogates in a regular
expression, as was once required.

Richard.

Re: Petition to ban Google from designing emoji

[Asmus Freytag via Unicode]

  
  
On 5/18/2017 10:40 AM, David Faulks via
  Unicode wrote:


  You cannot always tell things like these are
jokes, I have seen people argue seriously that Unicode should
dictate or enforce emojis before.


  

Many jokes contain a kernel of seriousness.
A./

  

Re: Petition to ban Google from designing emoji

[Phake Nick via Unicode]

Is it possible to introduce variation selector for emoji with large design
variation among vendors so that when users send emoji with selectors their
variation among vendors can be minimized by asking vendors to support both
versions?

Re: Petition to ban Google from designing emoji

[Rebecca T via Unicode]

Nick,

Don’t even joke.

Sincerely,
— Rebecca


On Thu, May 18, 2017 at 2:53 PM, Phake Nick via Unicode  wrote:

> Is it possible to introduce variation selector for emoji with large design
> variation among vendors so that when users send emoji with selectors their
> variation among vendors can be minimized by asking vendors to support both
> versions?
>