hasen

As I usually do with a lot of things, I tend to skim through, glossing over the details. And so, I thought embedding levels were merely a coding scheme that I can ignore and just pretend that an “odd” level means an RTL run. (I’m referring to my adventure with adding arabic support (complex layout) to scribus’s text frame).

I was wrong.

The problem manifests itself clearly when some arabic sample contains numbers. Because numbers run from left to right, they have an even embedding level. Consider this:

R1 ## R2

Where R1, R2 are RTL segments, and ## is a number.

You’d think this break the text into 3 runs: RR LL RR, but this is wrong! the whole thing is an RTL run, but it has an LTR run inside it.

Meaning, the text is to be displayed (visually) like this:

R2 ## R1

The text starts from the right, (even though it’s aligned to the left in this post).

You can’t describe this with merely linear monodirectional segments: you’ll get the wrong result. You have to have a “tree” of runs, where a run could have child runs embedded within it, so that it doesn’t break the surrounding text at the wrong place.

That’s why embedding levels are they way they are.

The above example would resolve to embedding levels (roughly) of:

11 22 11

(I say roughly because I’m not entirely sure how spaces are handled). The level for the number (sequence of digits) is 2, not 0.

So what we need to do, is reverse inner runs before reversing outer ones.

For comparison:

Edit:

I had some code here before, but it was wrong too :) so I deleted it.