On Mon, Aug 22, 2016 at 11:26 PM, Christoph Päper <
christoph.paeper_at_crissov.de> wrote:
> 1. it’s incomplete without an explicit neutral/ambiguous alternative and
>
As I said, people are actively investigating what to do about such cases.
It may be that the solution is to add ⚲ U+26B2 Neuter, but maybe not. We'll
see as they develop further.
2. if they need `Emoji=yes` as a result, this must also be applied to a
> bunch of related characters.
>
As I said, that is absolutely not a criterion.
If one were to apply that principle ("must be applied to a bunch of related
characters"), then because we have one playing-card emoji, we should make
all of the playing cards be emoji; because of one Mahjong tile, one would
add all of them. And then add all the chess pieces, and other game pieces.
And because we have a few circled or squared ideograph and katakana emoji,
make all the others emoji. And there are squared or negative ASCII emoji,
so add all of the others as emoji. And alchemical symbols, and ... I
suspect the transitive closure of this process could end up marking
essentially all Unicode characters with the Emoji property.
> commenting on was making a mistake, in my humble opinion, which could be
fixed easily by emojifying the mentioned sets of characters
The committee has and does consider related characters when looking at
properties. But this case was not an oversight. Those particular characters
were deliberately chosen. It is always possible to add other characters in
the future; it will depend on whether they are deemed to be necessary.
> When did character properties become vendor-driven? They should be based
upon actual writing habits, i.e. expectations of writers and readers.
An implementation can conform to Unicode and display all characters with a
colorful presentation, or all characters with a text presentation. So there
is nothing preventing you or anyone else from having an emoji font that
displays a any particular character with a colorful glyph. That is not the
purpose of the Emoji property.
The purpose for character properties is to promote interoperability. That
has always been the case. By having a property for Line_Break, for example,
Unicode gives implementations a common mechanism for producing
interoperable results (and for customization for particular environments).
The goal of the emoji properties is to have structure that promotes the
highest degree of interoperability among the major implementations
supporting emoji. It doesn't do any good for Unicode to mark a character as
being emoji unless that would result in it being widely deployed as such.
So the committee has to consider carefully what implementations will do.
That is nothing new; we have to consider carefully what the impact of any
change in property (such as Line_Break) will do in implementations.
You can certainly propose (via the reporting form), that any particular set
of additional characters should get the Emoji property, and try to make a
case for it. But I'd advise you to make a convincing case for your proposal
— *without using grounds that would apply to hundreds or thousands of other
characters*. In particular, you should address the question — for each of
those characters — of whether there is a strong expectation that it would
be frequently used.
Mark
Received on Wed Aug 24 2016 - 07:10:40 CDT
This archive was generated by hypermail 2.2.0 : Wed Aug 24 2016 - 07:10:41 CDT