From: Phillips, Addison (addison@amazon.com)
Date: Wed Jan 14 2009 - 23:50:12 CST
>
> Clearly many of the proposed emoji are not "already encoded" in any
> way,
> shape or form. Rather than stretch the existing definition of
> compatibility characters, can we have "interoperability characters"?
> Everyone who supports encoding these things claims they are needed
> for "interoperability", so calling them that would make sense.
>
Well, that's true. But looked at from the more expansive view: we wouldn't encode any of these characters (or "characters", if you prefer), except for compatibility purposes. One thing you learn, as you experience more with text encoding, is that very specific statements that are true in all cases are very rare.
Ken's citing of the box drawing characters is useful here. There are no other box drawing characters in Unicode. Yet these are still "compatibility characters". From one perspective, they could have been treated as a form of "font nonsense". Yet many applications (then... and essentially none today) relied on them for display in a textual context. Heck, I wrote a system (on a Nova back in the early 80's) that used them extensively in the UI on terminals. I would maintain---fiercely---that everything in those programs was text.
One of the points that Ken is making---and it is a useful point---is that "compatibility" is a separate, somewhat useful concept from (say) "compatibility decomposition". You're talking about the latter more than the former. Ken's point is that, while we may be used to saying "compatibility character" to mean the latter, it is actually a more extensive category than just that.
Addison
This archive was generated by hypermail 2.1.5 : Wed Jan 14 2009 - 23:52:48 CST