I think the best would be implementing both methods and letting the user choose the desired behavior thru an options screen.
I still haven't understood whether this only affects newly-written text or rendering of existing files as well.
If it affects rendering of existing files, then letting the user choose is not an option. A person who saves
a file wants its presentation to be predictable and not dependant on the user's options.
You can't go against the flow Microsoft set and it would be nice at the same time to have features that are better than Microsoft's.
Is it already a fact that it's better? Be careful not to choose an option as better automatically, just because it was the community that proposed it.
---
And now, for a few thoughts:
1. Do we know for fact what method Microsoft Office internally relies on, to render BiDi correctly?
There are the following options:
a) BiDi control characters (RLM/LRM/RLE/LRE),
b) The language tag assigned to those characters (requires them to write a non-standard BiDi algorithm, which receives,
in addition to the text string, a language tag for every character).
2. It *is* possible to get the IME language on XFree86, and on any X server which uses XKB.
Mozilla also has some code to get the current language from AIX IME server.
What's stopping us from implementing Microsoft's way on X too, then?
I think Microsoft's way is quite convenient; I use Word and Outlook on a daily basis and I must say that I enjoy
this feature, and I'm glad to find text fields which have this feature enabled.
3. If I'm not mistaken, when Word (XP, 2003) exports text to clipboard, it inserts directional characters to maintain
the appearance of the text in the target app. Even if we use Word-like "language tags" internally, with a non-standard
BiDi algorithm, we can give "outside" users (ie. other apps) a standard-compliant text to work with.
============================================================== To unsubscribe, send mail to [EMAIL PROTECTED] with "unsubscribe hebrew" in the message body.
