From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Mon Dec 29 2008 - 06:53:41 CST
On 12/29/2008 3:59 AM, James Kass 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.
>
Apparently not. It's functionally like mini-markup, if intended to
denote an emoticon.
> 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.
>
Using ASCII fallbacks is buggy. And a global emoticons on/off control
doesn't really cut it either. Whether user-selectable or not.
> 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.)
>
See, you are arguing for an encoding solution as well. Whether the use
of ZWJ is more beneficial than a dedicated encoding of the object itself
- that's the level of discussion where things begin to get productive,
because now you are comparing different solutions in the range of
possible types of encoding solutions.
I have my preferences, but that's for another time.
A./
This archive was generated by hypermail 2.1.5 : Fri Jan 02 2009 - 15:33:07 CST