[Adium-devl] Improving BiDi support

Ofri ofri.wolfus at gmail.com
Wed Sep 3 23:59:46 UTC 2008


On 04/09/2008, at 02:46, Evan Schoenberg wrote:

>
> On Sep 3, 2008, at 7:03 PM, Ofri wrote:
>
>> The problem begins when sending/receiving messages made up of only
>> weak characters and/or emoticons. If the message contains only weak
>> characters, the algorithm uses NSWritingDirectionNatural as the
>> direction, which aligns the message however defined in the message
>> style (which left unless someone uses an RTL style). The problem with
>> emoticons is that the direction algorithm is scanning the message  
>> as a
>> simple string without knowing anything about them, so if for  
>> example I
>> send the message ":-P" I'll be aligned left because "P" is a strong
>> LTR character.
>>
>> Based on the above, my improved BiDi algorithm goes like this:
>> 1. Remember the direction of the last sent and the last received
>> messages.
>> 2. When a new message is written/received, scan it for emoticons and
>> remove them. Keep the stripped string.
>
> Rather than stripping emoticons in a separate processing step  
> (expensive and cumbersome), an RTL determination filter should run  
> after emoticonification occurs.  It then will be able to neatly skip  
> over emoticons with ease.  If it skips over all characters in a  
> string, the string doesn't have a direction.  Then proceed with your  
> proposal as below:
>
>> 3. Try to determine the direction of the stripped message, using the
>> algorithm described above (implemented as an NSString category in the
>> FriBiDi framework).
>>   3.1 If the string has a direction, remember it and display the
>> complete message with that direction.
>>   3.2 If the string doesn't have a direction, assume it's a
>> continuation of the previous message and use the stored direction.
>>   3.3 The string doesn't have a direction, and there's no previous
>> direction.
>>     3.3.1 If the message is outgoing, use the input field's  
>> direction .
>>     3.3.2 If the message is incoming, use the previous outgoing
>> direction if available, and if not leave it up to the message style.
>> This assumes that if I initiated a conversation in one language, the
>> other side will usually answer in the same language.
>>
>> In addition, I also suggest a behavior change to the writing  
>> direction
>> contextual menu, which will disable it when we know the direction and
>> enable it when we don't. This will allow the user to override our
>> algorithm for some edge cases. This will also make the input of the
>> user consistent with the way it's displayed in the message view.
>
> "When we know the direction?"  If this is the user's input field,  
> can we know what the user is about to type?

No. What I meant was that as long as the text the user typed is  
neutral, we give him/her an option to force a direction. Once the  
typed text becomes not neutral, we disable that option.

Actually now that I think about it, this won't be so useful as it  
won't have any effect on the other side when using other protocols but  
MSN.

Ofri

> Cheers,
> Evan
>
>> This solution seems rather complex for something that's not critical
>> for the client to work, and that most users won't even notice (RTL
>> users are a minority AFAIK. BTW, why not to include this info with
>> Sparkle?). In addition, I don't know how easy it will be to strip
>> emoticons from a string (never touched that code), and if it'll slow
>> things down. Finally, I doubt I'll have the time to implement what I
>> described above anytime soon.
>>
>> What do other people think? Sure it'd be nice to be able to say that
>> Adium is the only IM client on all platforms that properly supports
>> BiDi conversations, but does it worth the effort?
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20080904/3e2c1197/attachment-0001.html>


More information about the devel mailing list