Thanks for your feedback. I managed to test XXE on our Mac and to reproduce the behavior you describe (I think it is platform independant).
The news are not good. In a nutshell: * We have understood why glyphs are shaped correctly. * We could fix everything related to caret location but... * ...there are severe font metrics problems with Arabic which would prevent us from getting something usable. Java seems to incorrectly measure the width (and to a lesser extent, the height) of arabic text. Java returns much too large dimensions, as if it simply added the width of each *unjoined* arabic glyph. (We use java.awt.FontMetrics.charsWidth().) We don't understand why this happens and we don't see any workaround. I'm sorry to have to say that we currently see nothing we can do to help you. --- PS: I have tried latest Jaxe (V2.0, http://jaxe.sourceforge.net/) on our Mac and didn't manage to type Arabic. My intent was to download their source code to see how they solved the font metrics problem. Reynolds-Gregg wrote: > Thanks for the quick response. Here's some more detail. I use > Windows2K Pro service pack 4 at work, and Mac OS X at home (the latest > version; I'll check when I get home and send the details). On my > windows machine Arabic support is enabled, but the locale is set to > English (United States). The Arabic (Qatar) input method is installed. > Other than that, nothing special that I know of. On the Mac, I just > enabled support for the Arabic keyboard - can't recall off the top of my > head the name of the applet in the system control panel, will send > later. Again, nothing special that I know of. > > In both cases I just installed XXE normally. Then I opened an XML > Docbook document that has Arabic text, and found that it was displayed > correctly, although aligned left instead of right (I can work around > this in my CSS stylesheet by setting justify right.) The letters are > shaped correctly and the lines run from right-to-left, top-to-bottom. > When I click to set the cursor it looks ok - the cursor appears in the > place where I click. But when I type, the input point is a dozen or so > characters to the left of the apparent insertion point. Just far enough > to make editing a little too difficult. > > Actually, I take it back. The caret behavior seems position-dependent. > I just now noticed that if I place the caret right in the middle of the > line, and strike a key, the character gets inserted under the cursor - > correctly. If I place the cursor on the left-hand side of the line, the > true insertion point is on the right-hand side, and vice-versa. And in > fact, the farther the cursor is from the center, the farther the true > insertion point is too. > > When inserting new text, it starts on the left and gets shoved over to > the right as I type. The caret stays on the extreme right. > > What's interesting is that the vast majority of XML editors have the > same or similar behavior. I've looked at 20+ editors so far and found > only Jaxe supports Arabic typing. Another supports Arabic typing in a > "DOM view" but not in the "Source view". > > I speculate that Java text services provide Arabic contextual shaping at > a fairly low level but maybe haven't completely implemented rtl > orientation. > > Regarding documents, we usually have a few English words and acronyms. > But for me it's a piece of cake to wrap such things in an XML element > and manipulate it as needed in an XSLT stylesheet. If I had an Arabic > Text widget that only supported rtl I would type acronyms backwards and > cut-and-paste longer chunks. It would be a minor annoyance compared to > the huge benefit of having Arabic support (by which I mean glyph-shaping > + rtl orientation, not the odious bidi algorithm). Converting such > "true plain text" Arabic into Unicode faux plaintext Arabic would be > simple. (Since I can safely assume that you have a personal interest in > Arabic support in general, I'll put it to you this way: the Unicode > bidi requirement amounts to an arbitrary hidden tax worth $billions on > everybody who uses an rtl language. It just isn't necessary - Arabic is > not bidirectional, nor is any other language, contrary to popular > belief.) Pierrick Brihaye wrote: > Hussein Shafie a ?crit : > >> Therefore we need to fully understand why you say ``Your editor already >> almost supports Arabic text''. > > > Here is my own experience on XXE 2.7 (Windows 98, JDK 1.4.2_01) : > >> We can easily understand why the caret behavior is incorrect: >> >> * We imagine that when you type a letter, the caret moves to the right, >> instead of moving to the left. > > > Yes. > >> * We imagine that when you click somewhere because you want to type text >> here, the caret is moved ``to the opposite side''. > > > Yes, but it looks more complicated. When you click on the middle of a letter, > the caret goes left, which is correct but inconsistent with the above > behaviour. When you click on the *very* beginning of a letter, the caret goes > right : I assume that the click considers this position as being in fact the > end of the previous letter. See below for a possible explanation... > >> * Similar odd behavior with text selection (i.e. you drag the mouse over >> text). > > > Yet more complicated : the left part of the selection (i.e. the end of the > selected text) is correct. The right part (i.e. the beginning of the > selection) of the selection falls in the middle of the letter. It *seems* the > this position is calculated on the basis of the isolated form of the letter. >
