From: Christopher Fynn (chris.fynn@gmail.com)
Date: Mon Jan 12 2009 - 01:05:24 CST
On 12/01/2009, James Kass <thunder-bird@earthlink.net> wrote:
...
> Whether these things remain viable in the PUA, get added to a
> plain-text standard (shudders), or are handled by another standard,
> they should be kept together as a set because *that* is their identity.
> The logos are already out and it looks like those flags won't fly.
> Pragmatic interoperability is already not gonna happen. Some
> kind of alternative solution seems to be in order.
...
*Yes!* If they are neccessary, my preference is would be to have a
block of emoji characters encoded for interoperability / compatibility
reasons (probably on plane 14). The whole lot encoded as a group and
none unified with existing UCS characters.
These should clearly be labled as "interoperability characters" and
their use for other purposes discouraged. These character could
simply be named EMOJIXXX. and representative glyphs avoided.
This way the the whole set would be there providing true
interoperability, we avoid having characters that would normally not
pass muster being encoded in the middle of existing blocks, and it
matters little if some of these are coloured, animated or contain
images of flags.
Simple black and white non animated symbols akin to some of the emoji
probably deserve encoding - but these should be encoded seperatly as
symbols - not unified with the emoji interoperability set.
- C
This archive was generated by hypermail 2.1.5 : Mon Jan 12 2009 - 01:07:10 CST