Re: Emoji: emoticons vs. literacy

From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Tue Jan 06 2009 - 10:42:55 CST

  • Next message: Christopher Fynn: "Re: Emoji and Search Engines"

    On 1/5/2009 9:57 PM, James Kass wrote:
    > Peter Constable wrote,
    >
    >
    >> But you're blurring the lines between plain text
    >> and markup: what you're suggesting *is* markup,
    >> but you're just calling it plain text.
    >>
    >
    > HTML source files are plain-text files. The mark-up
    > contained within consists of plain-text strings. Using
    > plain-text strings as mark-up blurs no lines, it's done
    > every day.
    >
    On the source level, HMTL can be edited as plain text. But to be HTML,
    it has to be recognized as such. Files are tagged with htm(l)
    extensions, or with other means of externally identifying their type,
    and internally, they contain announcers of their HTML nature and how
    strictly they observe the protocol definition.

    That's different from having data that should be 'raw' plain text
    contain unannounced markup sequences.
    > On the other hand, encoding icons as text crosses the
    > line between plain-text and rich-text.
    >
    That's a matter of opinion on which there simply isn't the iron-clad
    consensus in each instance that you are proclaiming in this discussion.

    The support of HEART, SMILING FACE etc. in plain text data streams
    precedes Unicode and goes back nearly thirty years (to the original IBM
    PC character set for one). Extending the existing list of "icons" in
    Unicode is not the dramatic step that you and other have made it out to
    be. Yes, doing so uses code space, and yes, some of the proposed symbols
    have novel renderings in some contexts, all good reasons to have a
    discussion and proceed with deliberation, but its not the sea-change
    that it's made out to be.

    Adding 40,000 rare ideographs and spelling out 11,192 Hangul syllables,
    on the other hand, *was* an example of a game changer: it required going
    from UCS-2 to UTF-16 or UTF-32. Yet the current discussion is dragged
    out to the degree that it's beginning to rival the discussions of that
    earlier, far more significant step.

    A./

    This archive was generated by hypermail 2.1.5 : Tue Jan 06 2009 - 10:44:42 CST