Added TestRTLBitmapText for issue #1158

[Ali-RS]

The expected result should be:

                                                                   to right test a is This
                                                                                .text left 

but it displays:

                                                                  .text left to right test 
                                                                                 a is This 

[pspeed42]

Thanks. The "RTL" instead of "Rtl" makes me a little sad... but I'm happy there is a test for this.

[Ali-RS]

The "RTL" instead of "Rtl" makes me a little sad...

Sorry, fixed it in this commit: 16ccd36

[pspeed42]

Hahah. Thanks. :)

[Aufricer]

I have looked a bit into that matter.
As @Ali-RS said in https://hub.jmonkeyengine.org/t/issue-with-line-wrapping-of-right-to-left-text-in-bitmaptext/42148/11
It seems BitmapFont and BitmapText classes are only holding alignements of the text. They dont do something on the position of characters in the text.

As a note, I try to show the workflow of how characters are applied and its position is determined:

Bitmaptext.updateLogicalState() -> calls assemble() --> calls Letter.class update()
-> available in that class are letterquads (created when the class was created or via settext) those letterquads are like a line called "head to tail"
In Letter.update -> Letterquad.update(Stringblock) is called. All letters are iterated and position of x and y is determined.
A variable incrScale is used in that calculation its created when Letters are created what is happening when Bitmaptext is created. Depending on the boolean "rightToLeft" is either 1 or - 1. As far as I understood its only multiplied with an bitmapChar.getXOffset() * sizeScale (in the testcase above it resulted always in "0") . So it had no influence on x or y at all.

In Letter.update also linewraps or wordraps are determined. Finally Letter.align() is called from Letter.update.
Here all letters/Letterquad (using the chain again) have there alignx and aligny calculated and set.
After returning to Bitmaptext.assemble --> textPages[i].assemble(letters); Here Buffers etc. are set.

To sum it up: For me Alignement only has an influence to the alignement of the text not to the wordflow. Parameter rightToLeft may only have an influence if the bitmapchar do have an offset.

Thinking of the complexity of the current Bitmaptext there is only two solutions to apply right to left text
a) rewrite bigger parts of the font package
b) try to adjust the text! before it is assembled

I will need to think about it later, but I think adding a new variable/parameter for righttoleft text should be added
Determining on that parameter the given text should be transformed before even the letter chain is created and the x + y position is calculated

BitMapText.java
private void assemble() {
ADDTEXTCONVERSION
// first generate quadlist
letters.update();
for (int i = 0; i < textPages.length; i++) {
textPages[i].assemble(letters);
}
needRefresh = false;
}

Not sure if it is as "easy" as transforming input from ABCD --> DCBA or if there is more calculation (as linewidth etc. necessary )

Just asked my arabic speaking wife. She said "Auto" would be "otuA" in arabic. I am still not sure about the linebreaks but its a starting point.

[Ali-RS]

@Aufricer, thanks so much for your interest and investigation on this!

Not sure if it is as "easy" as transforming input from ABCD --> DCBA

I believe this process should be done on the text entry (i.e Lemur TextField) where the user dynamically inserts text. (if we do this in BitmapText, it will ruin the static texts (i.e labels) where the provided text is already in RTL)

BitmapText should only deal with the line wrapping issue I believe, as I have demonstrated in the test. Maybe in the case of RTL text, we should process the chain from "tail to head"?

[Aufricer]

Good morning,

at breakfast I already sat with a paper and a pen.
I will look more into that topic. But after sleeping I would say a simple text concersion ABCD -> DCBA would not do the trick.
As you say - BitMaptext always applies from left to right. I will try to make pictures or an entry to JME hub later but think of a text A B C it will always apply A and B to line 1 and C to line 2. If you convert the text (C B A) in line 1 you find C B and in line 2 you find C. While in reality you want in line 1 A and B applied (but not on the left) and C in line 2.
So I feel rewriting the method might be necessary. I also thought about the parameter rightToLeft. If there is an offset of X in the character (or a kernamount) it moves the whole character a bit to the right or left. What makes sense if you have a font right to left you need to add the offsets the other way.
Thus maybe that boolean must be also used to determine if the letters starting at x = 0 and then go to the widht of the tectbox or if they start at x = textboxwitdht and then go towards 0.

[Ali-RS]

ABCD

So just to be clear, is the A in your example a letter or a word or a sentence?
In your first post, I tought you mean it as a letter.

[Aufricer]

Letter. The wrapping (word, letter, ) happens in said letters.update as well. It had to be ajusted as well when coming from the right side.
For lemur I have my own wordwrap functionality. But even if you only implement it to lemur only, you need to calculate the width of each letter/word/ line to check if it is > width of the given textblock.
I would say its best done in letters/letterquad and Bitmaptext. Most of the logic is already there.

[Ali-RS]

Not sure if it is as "easy" as transforming input from ABCD --> DCBA

if we do this in BitmapText, it will ruin the static texts (i.e labels) where the provided text is already in RTL

@Aufricer, sorry I was wrong about this. You are right that we need to inverse the letters in BitmapText. I just realized that char arrays returned by String.toCharArray() on an RTL text contain the characters from right to left (index 0 references to the first letter from the right). So to properly render it on BitmapText we need to reverse it.

String s = "کتاب"; 
for (int i = 0; i < s.length(); i++) {
    System.out.println("char at (" + i + ") is => " + s.charAt(i));
}

output:

char at (0) is => ک
char at (1) is => ت
char at (2) is => ا
char at (3) is => ب

[Aufricer]

left orientet

right orientet

I just need to look where the extra movement of some characters come from.

I also need to build a reverse text into it.

Arabic/persian letters written or put into code --> DCBA but still need to be inputed to BitmapFont like ABCD as it got reversed there again

[Ali-RS]

Yes, I see it now. Thanks!

[Aufricer]

I tried to enter این یک متن آزمایشی می باشد to my SDK but its not accepted there... So I think you or someone with the capability need to test it then.
Currently the first letter on the right would be د followed by ش if you put it like above to Bitmapfont. Therefore you need to inverse it first in the settext function ??? So in other words you make ای... out of it that it finally is reverted from right to left as ای

[Aufricer]