Ahlan wa Sahlan, 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.) I hope that helps. If I can provide any further info let me know. Sincerely, Gregg Reynolds > -----Original Message----- > From: Hussein Shafie [mailto:hussein at pixware.fr] > Sent: Monday, November 08, 2004 4:12 AM > To: Reynolds-Gregg > Cc: xmleditor-support at xmlmind.com > Subject: Re: [XXE] Writing direction > > > Reynolds-Gregg wrote: > > What are the chances of getting support for right-to-left editing? > > Note that this is not a request for bidi support. Support for the > > bidi algorithm is not necessary for Arabic; all that is needed is > > glyph shaping and right-to-left editing. Numbers can be > wrapped in an > > xml element and transformed to generate Unicode-compliant text. > > > > Your editor already almost supports Arabic text. It shapes the > > characters correctly, and allows editing. The only problem is that > > the cursor behavior is incorrect - it doesn't accurately > indicate the > > current point. This is the case for all the XML editors > I've tried - > > Oxygen, Morphon, and XMLBlueprint. The only remaining > thing I need is > > for the cursor to correctly show the insertion point. > > > > If you can implement right-to-left editing there is a least > a chance > > that I could generate some sales for you from my client. I > love your > > editor, but some kind of Arabic support is essential. Without that > > support there is no possibility. > > In order to give you an answer, we need to evaluate the exact > amount of > work to be done. > > Therefore we need to fully understand why you say ``Your > editor already > almost supports Arabic text''. > > 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. > > * We imagine that when you click somewhere because you want > to type text > here, the caret is moved ``to the opposite side''. > > * Similar odd behavior with text selection (i.e. you drag the > mouse over > text). > > What we don't see is: > > * What version of MacOSX are you using? > * What locale are you using? > * What keyboard are you using? > In a nutshell, what do we need to do to type Arabic on our Mac, just > like you do? > > * Do you write pure Arabic documents? Don't you need to also type an > English word from time to time? > > * How can Java *shape* letters correctly? We have done > *nothing at all* > to help Java at this. Unlike Morphon for example, XXE does > not use the > standard javax.swing.text.* classes. And we don't even support input > methods. This is a real mystery... > > --- > PS: Yours truly can speak, read and write Arabic (I'm Egyptian). > >
