Re: [UTR#51-8] 1.4.3 Emoji Variation Sequences: Female/Venus and Male/Mars Signs

JFTR, on the meantime, I had already resubmitted my original post through the proper feedback channel as a comment on the current draft of TR51.

Mark Davis ☕️ <mark_at_macchiato.com>:
>
> Similarity or containment in the same block as current emoji characters is not sufficient grounds for changing characters to have the Emoji property (…).

I’m not arguing on either of those grounds. I’m saying that U+2640 and U+2642 are integral parts of several sets and it will confuse and annoy users of all kinds if some of them can be emojis and some cannot. If these two symbols had been used as emojis before, the case would be slightly different, but they’re becoming emojis just because they’re *intended* to be used in certain ZWJ sequences. That’s why, for instance, U+1F170/1 🅰️/🅱️ (as in blood types) don’t necessarily constitute a reason to emojify U+1F172–89, too.

If Female Sign and Male Sign shall be emojis, but

- U+2609 ☉ Sun
- U+263C ☼ White Sun with Rays
- U+263F ☿ Mercury
- U+2641 ♁ Earth
- U+2643 ♃ Jupiter
- U+2644 ♄ Saturn
- U+2645 ♅ Uranus
- U+26E2 ⛢ Astronomical Symbol for Uranus
- U+2646 ♆ Neptune
- U+2647 ♇ Pluto
- U+263D ☽ First Quarter Moon
- U+263E ☾ Last Quarter Moon

shall not, you better disunify them from the symbols for Venus and Mars first. You’d also need separate code-points for Male Heterosexuality and Female Heterosexuality to go with Homosexuality and Bisexuality signs (“sexuality” = preference)

- ⚢ U+26A2 Doubled Female Sign
- ⚣ U+26A3 Doubled Male Sign
- ⚤ U+26A4 Interlocked Female and Male Sign

as well as Cisgendered Sexuality (maybe in male and female variants, “sexuality” = identity) to go with any of the Transgendered Signs

- ⚥ U+26A5 Male and Female Sign
- ⚦ U+26A6 Male with Stroke Sign
- ⚧ U+26A7 Male with Stroke and Male and Female Sign

and finally Feminine and Masculine to go with

- ⚲ U+26B2 Neuter.

> If there is a particular set of existing characters that you would like to propose to become Emoji (eg, to have the Emoji binary property), see information at http://unicode.org/emoji/selection.html#existing for how to do so.

I was only pointing out that the draft I was commenting on was making a mistake, in my humble opinion, which could be fixed easily by emojifying the mentioned sets of characters instead of just an arbitrary two-piece subset. If my objection was rejected I could and probably would then open a separate proposal, but it would seem ridiculously redundant doing that right now, because whether I proposed astro_o_ic or gender and sexuality emoji or all of them at once, it would have to include U+2640/2.

>>> Proposing to change the emoji properties to include existing characters or sequences as emoji is a much simpler process than submitting a proposal for a new character. The proposal need only provide evidence that an emoji presentation of those characters or sequences would be supported by a reasonably broad set of vendors.

That’s really only a simpler process if you are working for an important vendor and can convince another one – whose representative-in-charge you may know from a random standardization committee – to deploy fonts with an emoji glyph for a certain character. Even if someone like me would compile a number of fonts from FOSS image emoji collections (that go beyond the current canon) or could convince Emoji One and Twemoji to emojify a certain code-point, one couldn’t be sure at all that this was considered a “reasonably broad set of vendors”. Take U+1F946 🥆 as a counter-example: it used to have preliminary support as an emoji by Google/Android and I think still has in Emoji One, but was still successfully lobbied by other big names to not become an emoji character. <https://web.archive.org/web/20160610182948/http://emojipedia.org/rifle/>

When did character properties become vendor-driven? They should be based upon actual writing habits, i.e. expectations of writers and readers. The `Emoji` property is no exception to that, despite the history of the original set of emoji characters. I really can’t see how you could justify the emojification of U+2640 and U+2642 (and not related characters) except by saying “Google and Apple want so, because they need them for some new thing”. Did anyone actually bother to gather empirical data of emoji/symbol sequences in existing content to denote gendered professions?

It’s a really bad move and that’s what I’m criticizing about the eighth draft of UTR #51.

I don’t disagree with ♀ and ♂ being used as the second part in ZWJ emoji sequences, but

1. it’s incomplete without an explicit neutral/ambiguous alternative and
2. if they need `Emoji=yes` as a result, this must also be applied to a bunch of related characters.
Received on Mon Aug 22 2016 - 16:27:08 CDT