[Pending] Adding support for Right-to-left languages (Hebrew, Arabic...) (2 Viewers)

[velis]

Sorry I couldn't write the sample in C#, seems Python was too different

IMHO, the errors in rendering are because:
1. It seems whitespace is not the only thing that should be processed differently: symbols should too (0x00 - 0x2f, 0x3a - 0x3f, 0x5b - 0x5f, 0x7b - 0x7f)
2. The "<space>2" is a problem because you don't take into account that the locale is RTL. The spaces around reversed direction script section should be rendered as part of original script direction. Only the spaces within reversed script section should render as part of that section direction. Darn, this sounds complicated but it's not.

 

[morpheus_xx]

This sounds reasonable, will try to implement this!

 

[morpheus_xx]

I spent some more hours in testing of algorithmen, none was perfect (no surprise though!). So back to start.

As I've read about DirectWrite, I digged more into the API description and found very useful things for our task:

• http://sharpdx.org/documentation/api/t-sharpdx-directwrite-textlayout
• http://sharpdx.org/documentation/api/m-sharpdx-directwrite-bitmaprendertarget-drawglyphrun-1

TextLayout does everything which I tried to implement manually. In combination with a custom renderer this brings us much further now. I implemented a custom renderer, which now takes the "pre-processed" textparts, along with position info and an RTL/LTR indicator.
My current logic still tries to bring string into matching order. This will have issues and is only temporary.

The final solution will be to let the custom renderer directly create the BitmapCharacters and their positions. Once this is done, we should have correct support for LTR, RTL and mixed contents.

For code look at: https://github.com/morpheusxx/Media...AssetCore/TextRenderOrderProcessor.cs#L43-L63

 

[morpheus_xx]

After two days of vacation I continued the switch to DirectWrite based layouting. Once I've set correct font sizes and direction factors (-1/1) the result is nearly correct:

The only differences remaining are caused by different kerning / offset values from FreeType / DirectWrite implementation: you'll see a small "cut off" on left side of RTL-strings and some "scollable margins" on right side (text one above "Latest media" starts to scroll on focus)

 

[morpheus_xx]

The more steps you take, the more problems you encounter

I've added RTL support for TextBuffer, scrolling larger text now considers RTL if selected culture depends on it.

Then I introduced "default HorizontalAlignment" for controls and removed explicit values from XAML. The results are now as following:

And for the latest example you can clearly see problems: the MediaItem buttons are using a GridPanel to layout contents. The category/title label now sticks on the right side. This would only be good, if the order would be swapped as well: Icon, title and last (left) the count.

Not sure how to proceed here...

 

[morpheus_xx]

I was probably too fast to change the control's code. If I start at screen level and include a "mirror" into render matrix:

    public RenderContext CreateInitialRenderContext()
    {
      Matrix transform = Matrix.Scaling((float)SkinContext.WindowSize.Width / _skinWidth, (float)SkinContext.WindowSize.Height / _skinHeight, 1);
      if (ServiceRegistration.Get<ILocalization>().CurrentCulture.TextInfo.IsRightToLeft)
        transform *= Matrix.Scaling(-1.0f, 1, 1) * Matrix.Translation(SkinContext.WindowSize.Width, 0, 0);
      return new RenderContext(transform, new RectangleF(0, 0, _skinWidth, _skinHeight));
    }

This is the rendered result:

Everything is mirrored, but all controls are working properly!

Remaining issue: The rendering of text should not be mirrored, but using orginal layout (at correct position!)

 

[velis]

I like what I see in the last post
Can you calculate text width without rendering it? Then you could render the text using another mirror matrix from its end point.

 

[FreakyJ]

How much impact does the RTL support have on the performance?

 

[morpheus_xx]

How much impact does the RTL support have on the performance?

I'd say close to zero impact. It involves only some matrix multiplications and the alternative measuring call using DirectWrite. For LTR you won't notice changes at all.

I worked on the mirroring layout and got a good step further. Text is now "mirrored back" to normal and will be shifted to opposite half of screen. There are still some minor things to solve, but in principle this should work well:

Now it gets a bit more complicated if you look at Titanium screenshots:

While it looks good first, you'll notice that also graphics are mirrored! This is bad obviously, but may we can treat them like label and don't mirror them at all. I'll have to check how it could work, maybe we need to implement the logic the opposite way around.
Btw, currently this effect would also be visible for video frames (as they are in principle textures as well).

Can someone who is able to read Hebrew confirm that the screen content is correctly? No mirrored texts?

 

[ysmp]

Hi Morph',
my wife say all text is correct in all screens...
only one issue ... in screen movies (the oblivion screenshot) the ":" not in the the correct side ... they need to be on left side....
in the movie info labels .... see screenshot ....