I recently posted on an the HaxeFlixel forums about an issue where Arabic text appears with two problems:
- Letters are displayed left-to-right instead of right-to-left
- Letters are disjointed (cut-up) instead of being smoothly connected
These problems also appear in OpenFL. I generated a trivial Hello World example using the
AddingText OpenFL sample here, on GitHib.
I didn’t see any settings to trigger right-to-left (RTL). Is there one? Is there any way to make this work?
I’m pretty sure the font itself is correct. It does have the correct letters in it.
I need this to work on Android, Neko, and Flash, if that matters. (I know Arabic font support on Andorid is poor or non-existent, but I’ll cross that bridge once I have Flash and Neko working at least.)
Text rendering in OpenFL legacy is done in strictly left-to-right, simple layout.
One of the core problems we wanted to solve with the new OpenFL and Lime implementation was building up support for Unicode text input and text rendering.
As you may know, we should have unicode support for complex text input, so that’s one important threshold we crossed. We use the Harfbuzz library within Lime in order to get the correct placement of complex text, but this is where things get more complicated – or reveal the rough edges of what still needs more work
Harfbuzz wants you to specify information about the language, such as whether it is right-to-left, before performing a layout. We don’t push this information in at the moment, so though we have a strong library available for proper layout, we are not (yet) using it to its potential for right-to-left languages.
The second step after correct layout data is to use this for rendering, but we are pushing code through Cairo text support for simplicity and better performance than our older render code, but this disregards most of our layout data. We need to wire Harfbuzz layout to a different (probably custom) renderer, and as I mentioned above, have a way to specify the correct arguments to Harfbuzz for different languages.
Now we are on a much better foundation for this support, but it still needs more work to be supported
any chance with solving this problem in the past 3 years???
@mostaff_G The browser (in HTML5) is entirely in charge of rendering there, so we can’t really do much to improve however that works, without switching away from canvas text rendering.
Current versions of OpenFL use Harfbuzz internally for layout. It would be possible to modify our sources directly to force right-to-left:
We don’t support a way of changing this outside the source files. I’m not sure how Flash does it?
flash.text.TextField does not handle RTL text, so I think this would be OpenFL-specific. Flash’s TLF TextField can handle RTL and other things, and it is open source, but it’s significantly more involved and probably way slower than a normal TextField.
As a sidenote:
Text Layout Framework (TLF) uses proprietary
Flash Text Engine (FTE)
I mean, it cannot be ported
I can also agree that basic
TextField in Flash does not handle RTL and we had to use
TLFTextField which was significantly slower than the original
Maybe it’s worth discussing what aspects of TLF TF should end up in OpenFL TF. RTL was pretty lightweight to implement (assuming my RTL PR isn’t horribly wrong), but autodetection of LTR/RTL would slow things down a lot.
I like how the TLF source organizes things, even if it is a little much.