Thanks. I’ve made some progress with getting TextBox2 to (mostly) deal properly with diacritics - it just needs to configure an Arabic Reshaper object in the same way as the TextStim does. That code is still sitting on my computer though, as it only solves part of the problem. i.e. I’ve not been able to get anywhere with solving the issue of multiline right-to-left text starting from the bottom of the page. That bit of the code is too complex for me to try to change.
Would need some input from @TParsons on that front.
Todd - in essence, we are currently hacking right-to-left text (in both TextStim and TextBox2) by simply reversing the logical string (via the bidi algorithm for the fancy stuff) and feeding it to a stimulus that is still fundamentally displaying a string of characters left-to-right. i.e. the characters are always displayed from an origin at the top-left of the stimulus, with each glyph marching one step further to the right. So things (appear to) work for a single line of RTL text, simply by the trick of reversing the string. But this must break for a multi-line piece of text, as the first character of the original unreversed string will always end up as the last character in the stimulus (at the bottom-right). We need it to start at the top-right of the stimulus.
So in essence, instead of a fixed origin (top-left) and fixed directional increment (one step rightward), we need both of those parameters to be variables that alter depending on the direction of the text. i.e.:
- Left-to-right text: origin = top-left of bounding box, glyph increment = 1 step rightward.
- Right-to-left text: origin = top-right of bounding box, glyph increment = 1 step leftward.
- Regardless of text direction, at the end of each line, the vertical drawing coordinate is incremented one line lower down the screen, and the horizontal coordinate is reset to the starting value.
(I’m assuming here left- or right-aligned text format: ignoring the possibility of centre-aligned text, simply because I don’t understand how that works - I guess the origin in that case needs to be calculated on a per-line basis, depending on the length of text in that line?)
If we adopted this approach, we would then no longer need to reverse the string for displaying RTL text. That is, the logical order (i.e. the order in which characters are typed) would be preserved for both LTR and RTL text, only the order of drawing would vary between them. This is in contrast to the current situation, where the order of drawing is fixed, and so we need to reverse the logical order of the RTL string.
If it helps, imagine a RTL language which is simply English but read right-to-left. So an English phrase would be:
The cat sat.
To display this to be read from RTL, we currently just reverse the string, so we can still draw it progressively from left-to-right:
.tas tac ehT
This makes sense when read from right to left. But if the text stimulus gets too narrow, then the line would break like this:
.tas tac
ehT
This is the issue being reported by @Alaa. The logical order of the text is now broken: it would be read in order (from top-right to bottom right) as cat sat. The. But if instead of reversing the string, we preserved its logical order but drew it progressing rightward from an origin at the top right, it would look like the following (with the line break changing naturally):
tac ehT
.tas
Does this idea of varying the origin and the glyph-increment direction at a low, drawing level within TextBox2, make sense?
I’m ignoring that there are some situations (e.g. in formal Japanese) where the characters flow from an origin at top-right but down the page, rather than right-to-left.
e.g.
s T
a h
t e
.
c
a
t
We could/should ignore that for the time-being, but it does show that for complete generalisation, the glyph-increment direction variable would ideally be free to vary between a step downwards as well as a step leftwards or rightwards. There are apparently some languages that read up the page, but they are probably rare enough to not worry about…
