flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: RTL text
Date Thu, 26 Dec 2013 16:28:19 GMT
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
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.

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message