Re: The management of the encoding process of emoji
An issue that seems to be coming into prominence is that as a result of the requirement that emoji proposals should not be overly specific, some recent proposals seem to be trying to emphasise that they are not overly specific by suggesting that the particular emoji proposed could mean various things. This seems to present increasing ambiguity of meaning. http://unicode.org/emoji/selection.html#Specific Now, the overly in overly specific is rather subjective in its interpretation. Yet is the pendulum swinging too far the other way perhaps? Some readers may already know of the following video from the Unicode 39 Conference in 2015. https://www.youtube.com/watch?v=9ldSVbXbjl4 William Overington Friday 7 July 2017
Re: The management of the encoding process of emoji
William_J_G Overington: > > http://www.unicode.org/L2/L2017/17192-response-cmts.pdf > http://www.unicode.org/L2/L2017/17147-emoji-subcommittee.pdf > >> Two key issues are whether the characters are likely to be popular >> and whether they would be supported by major vendors. > > I am rather concerned at what I am calling majorvendorism. (...) > only new ideas acceptable to at least one of a small number of major vendors > can make progress. I very much share this concern. > (...) a font produced other than by a major vendor could become widely used > even though it is not bundled with an operating system. > > So there seems to me to be no fair reason for Unicode Inc. to include > majorvendorism in its decision-making process. > > If a major vendor chooses, for commercial reasons, not to support some emoji > then that is a matter for that major vendor and should not be a factor in the > Unicode encoding process. I'm about to propose emojis for several body parts and am afraid that, although there is huge demand and a lot of prior art for them, it's futile for reproductive organs, because American vendors in particular, who make up the vast majority of (voting members in) the consortium, have a history of self-censorship in this regard (cf. Egyptian hieroglyphics) which they likely will extend upon others because they *feel* obliged to support graphically explicit images in their own emoji sets. That's just speculation, of course, because I don't and can't know whether there already has been a similar proposal that the ESC just declined to publish and forward to the UTC. This lack of documentation is a major point of L2/17-147, which hopefully gets addressed soon in the very basic way mentioned in 3.c. of the response: >> The ESC has been working on a list of at least the submitted names for >> proposed emoji, >> and is planning to make that public in the near future. It's also not unfounded speculation, as the case of the Rifle character shows, which made it into late beta stage of Unicode 9.0 as an emoji, but had its Emoji property withdrawn after a joint request by Apple and Google. Some vendors had already added support for it, but dropped it because they somehow felt obliged to not ship multi-color glyphs for "arbitrary" characters (whereas vendors such as Microsoft and Samsung, a non-member, rightfully don't seem to care much about that). If emojis were treated as proper characters that can come from any font, there would hardly be a problem, at least on platforms where users can install or embed custom typefaces. The fact that some vendors are either not able or not willing to change how emojis work on their operating systems, should not impact the proposal and encoding process for Unicode characters.
The management of the encoding process of emoji
I have been reading the following document. http://www.unicode.org/L2/L2017/17192-response-cmts.pdf Comments in response to L2-17/147 To: UTC From: Peter Edberg & Mark Davis, for the Emoji Subcommittee Date: 2017 June 15 For convenience, here is a link to the L2-17/147 document. http://www.unicode.org/L2/L2017/17147-emoji-subcommittee.pdf In relation to the 17192-response-cmts.pdf document I write about two particular matters. In section 3.b of the document, there is the following. > ...; a great many proposals are received, many in an informal way, and many > are ill-formed (a significant number come from children). How does Unicode Inc. respond to children please? As emoji are picture characters, just pieces of art, rather than something with safety issues such as, say, designing a new railway locomotive, is encouragement given to the children? In section 2.a.iv is the following. > Two key issues are whether the characters are likely to be popular and > whether they would be supported by major vendors. I am rather concerned at what I am calling majorvendorism. I am concerned that progress in encoding may become subject to majorvendorization whereby only new ideas acceptable to at least one of a small number of major vendors can make progress. On many modern personal computers, fonts used by an end user do not necessarily need to have been produced by the producer of the operating system. Mostly, application programs can use any font that complies to the font standard. Fonts can be produced by many people, including an individual sat at home using a home computer using budget fontmaking software. That includes colour fonts. Fonts can be distributed electronically over the Internet, either for a fee or at no charge as desired by the publisher of the font. So a font produced other than by a major vendor could become widely used even though it is not bundled with an operating system. So there seems to me to be no fair reason for Unicode Inc. to include majorvendorism in its decision-making process. If a major vendor chooses, for commercial reasons, not to support some emoji then that is a matter for that major vendor and should not be a factor in the Unicode encoding process. I opine that progress should not be majorvendorized as that may impede the implementation of new ideas from individuals and small enterprises and new enterprises that are not connected to a major vendor. William Overington Saturday 17 June 2017
