Re: Emoji: emoticons vs. literacy

From: Asmus Freytag (
Date: Fri Jan 02 2009 - 17:53:27 CST

  • Next message: Asmus Freytag: "Re: Emoji: emoticons vs. literacy"

    On 1/1/2009 11:55 PM, James Kass wrote:
    > Peter Constable wrote,
    >> It's also axiomatic that the data passed through a plain-text
    >> protocol is plain text, a sequence of abstract characters, however
    >> that data may have originated at the source or be processed at its
    >> destination.
    >> [There are] some simple realities that UTC sees before it:
    >> - data exchanged in plain-text protocols consists solely of abstract
    >> characters
    > ...including private use or user-defined characters which
    > would otherwise be unsuitable candidates for encoding.
    These are called "compatibility characters".
    >> - the goal of the Universal Character Set is to be universal,
    >> implying (among other things) that any set of characters with
    >> significant usage in ICT industries must be considered potential
    >> candidates for encoding
    > ...unless they are unsuited for plain text encoding because
    > of their very nature.
    Such as, for example, stateful controls, code-set shifting commands and
    other strange beasts, that would be difficult, if not impossible to
    handle as compatibility characters. I can easily conceive of more exotic
    examples, if that helps.

    However, in the case under discussion, all character codes encode single
    text-elements in a 1:1 fashion. One code per symbol. A large(?) subset
    of these characters is also unremarkable. They are just particular
    examples of yet more miscellaneous symbols. They are not even really
    compatibility characters. So, what the discussion is about is the
    remaining set of characters, which violate one or the other criteria for
    encoding as regular characters.

    These are the true compatibility characters. Compatibility characters
    are the means by which Unicode handles the fact that there are external
    plain text protocols that contain abstract characters that would not
    normally qualify as abstract characters under the criteria internal to

    In the set that is under discussion, none seem immediately unsuitable as
    *compatibility* characters (except logos are firmly out for legal, not
    technical reasons).

    >>> Who is supporting the proposal? (Committee members unanimously,
    >>> and a few others.)
    >>> Who is opposing the proposal? (Independents, many of whom are
    >>> unpaid volunteers, or whose livelihood does not depend on the
    >>> encoding process.)
    > Substitute prestige for livelihood.
    What's that supposed to mean? I find this aspect of the discussion
    rather strange.
    >> This is a flame..
    Not going there.


    This archive was generated by hypermail 2.1.5 : Fri Jan 02 2009 - 17:56:37 CST