In all examples (the Test project in jME 3.0 or jME 3.1) setting the boolean flag “rightToLeft” (the second c’tor param) has no effect on the text - it always renders from left-to-right on my machine.
That’s especially strange since some years ago it seemed to have worked.
Can anyone please check if they can change the rendering direction?, For example in: TestBitmapFont.java TestBitmapText3D.java
I even used Arabic text and it did not look like in the Google Translator:
JME’s bitmap text does not support bi-directional texts like Arabic and Persian.
Unlike English or many other languages, letters can stick to each other in Arabic/Persian … so based on the letter position in a word (a letter can sit at first, between or at end of the word) same letter can have different glyphs.
But JME’s bitmap font library is not able to place the correct form of glyph based on letter position and it just uses one default glyph regardless of where the letter is positioned.
I am using JME-TrueTypeFont. [ because most/all of the free Arabic/Persian fonts i could find in web were in ttf format]. I wrote a converter to support Arabic/Persian/… text for ttf fonts. At behind it uses @yn97 's parser but mapped to support true type font and Textfield in Lemur Dynamo. (So it can convert your text while you are typing)
That’s good to know and I would very much like to grab some code to make a TryderTextBox or something like that.
But the problem I see is that the BitmapText from jME has a right-to-left option but if you activate it then “123” is still being rendered as “123” and not as “321”.
I remember my tests in 2013/2014 when things worked.
I know that in Arabic the letter is written differently when being at the start, middle or end. There are glyphs for that in the Unicode standard. Taking care of that should not be such a big problem if one knows the rules for this.
For support of bi-directional I wrote a routine for BitmapText some years ago that simply switched numbers and Latin letters at word boundaries but let the Arabic words in their order right-to-left. Looked quite promising but never can be as adequate as the Bidi-algorithm from Unicode (which is very complex). I wrote Unicode support in a way that it tells me for each glyph whether it’s supposed to be written right-to-left (includes Hebrew too).
There are also two glyphs in the Unicode standard that say “switch to left-to-right now” and “switch to right-to-left” now.
Sadly, the Unicode standard does not yet support vertical text (“switch to vertical Asian now”, “switch to vertical Mongolian now”, “rotate glyph by 90 degrees”, “rotate glyph by 270 degrees”). So there are still some imperfections to Unicode’s support for other text flows. Just like their support for Emojis is still under development.
Tested with TestBitmapFont.java
setting txt.setAlignment(BitmapFont.Align.Right); just position the whole text to start from right txt.setText("Hello, How Are You ?");
No, that’s horizontal alignment. That works as it should.
What I mean is the text flow (called “line progression” by professionals).
Try to create a BitmapText with the second parameter set to true or false → makes no difference…
