From: James Kass (firstname.lastname@example.org)
Date: Mon Dec 29 2008 - 05:59:36 CST
Asmus Freytag wrote,
>> Sorry, I cannot follow the logic. If some software turns 8) into a
>> small image, then this is either an error or intentional behavior. In
>> this case, it is probably intentional, and the question arises whether
>> and how the feature can be switched off by users; but this a practical
>> software issue (which would equally exist if the characters were
>> turned into an emoticon character).
>The problem stems from the fact that in this kind of scenario 8) is no
>longer unique in the encoding sense. In order to determine whether text
>containing 8) intends to encode the digit eight followed by the close
>paren or in fact intends to encode an emoticon you now need out of band
>information. Requiring out of band information for text content is
>certainly not ideal. Therefore, if there were dedicated character codes
>for emoticons (especially those using short, and therefore commonly
>occurring strings of punctuation marks as fallbacks) the ability to used
>them as a unique way to encode common emoticons would be a definite benefit.
A digit 8 followed by a closing parenthesis is just that.
Any application which changes "8)" into anything other than what
it is, without the user's permission to do so... Well, some
of us still consider that kind of behavior to be buggy.
If anyone really needs to replace an ASCII string with an emoticon,
they'd be asking for a 'more joined form' of that string, in a manner
of speaking. Let them use ZWJ, if they must. The onus shouldn't
be on the encoders to encode atomic 'more joined forms' when such
forms can already be expressed using an existing Unicode sequence
invoking the existing ZWJ mechanism. (Naturally, determining if,
when, and how such 'ligatures' would be displayed would be left
up to display engineers. A rich-text application might choose
to substitute a graphic.)
This archive was generated by hypermail 2.1.5 : Fri Jan 02 2009 - 15:33:07 CST