I'm very familiar with bidi composition and the issues therein. Here's some (not very well organized) thoughts:
In my opinion, InDesign has done it right. In InDesign, direction can be set on many levels. Some make sense in Flex, some don't. There's character direction which can be r-t-l, l-t-r, or default. There's paragraph direction, which sets the general direction of the paragraph. There's table direction. There's story direction which controls the order of columns in multi-column text frames. There's binding direction. Binding direction makes no sense in Flex. That leaves us with 4 distinct settings. The way it works now, Direction.RTL and Direction.LTR applies to everything. There's a few problems with this: 1) The three levels of control on the character level is very useful. Besides allowing the forcing of composition reversed from the natural composition (i.e. drow instead of word), it allows for dealing with edge cases where it's necessary to force progression of neutral characters. 2) It's possible to want to set the column direction different than paragraph/character direction. I have not spent enough time looking into exactly how direction and neutral characters work, but here's how it works in InDesign: 1) Paragraph direction sets the general flow of the paragraph. Each block of r-t-l or r-t-l text is composed naturally, but the placement of the blocks relative to each other is controlled by the paragraph direction. For example, trailing punctuation will be to the left of r-t-l paragraph, but to the right of a l-t-r paragraph. 2) Neutral characters surrounded on BOTH sides by same direction (either r-t-l or l-t-r) will follow the natural progression of the surrounding text. NOT the direction of the paragraph. This can be overridden by setting the direction of these neutral characters, but this is normally what you'd expect. 3) Numbers progress left to right, but they are considered neutral in regard to block progression of the relative text. Harbs On Dec 24, 2013, at 5:12 PM, Michael A. Labriola wrote: >>> And the label displays "!Hi there" is that expected? > >> Yes, that is correct in this case. The Hi There are Latin characters which >> carry information in Unicode to indicate they should be displayed LTR. >> However, the punctuation mark is a weak character (can be used in both >and >> doesn't have this type of information) so the placement of that mark is >> determined by the bidirectional algorithm. In this case, since you specified >> rtl, it used that info to decide the punctuation mark should be >positioned >> at the end of the word reading RTL. > > One last comment on this: This is actually a place where things could use a > bit of polish in general. In this case, since the weak character (!) was > following a run (continuous grouping) of LTR characters, it would have been > nice for the BiDi algorithm to note that fact and place the ! at the end of > the 'Hi there'. > > In BiDi text you might get a group of characters written RTL, then a group > written LTR (Imagine an Arabic language review of an English language film; > the review would be in Arabic, but the title of the film would still be > written LTR in English). When you have weak characters at these transition > points it is often very difficult to determine the placement, so the BiDi > algorithm will often fail upward to determine the direction. So, in other > words, picking up the rtl you had set on the application as the overarching > direction when it's not sure. This, however, should be more of a last resort > thing and it should really try a bit harder first. This particular issue was > determinable IMO. That said, these types of issues are fairly common in BiDi > algorithms and so while I think it could be better, it's understandable. > > So, when I said it's correct, it's probably better to say that it is the way > it has always worked since the received the first RTL support. It could be > better, but there are actually a lot of little issues like this in the > algorithm being used that were deemed good enough years back. Whether they > are still good enough likely depends on the availability of someone with the > knowledge and time to get into this. > > Mike > > >
