Trying this sample in our XamlPlayer I see that individual glyphs are correctly rendered (each glyph texture bounds is correct), but it seems the "advance" is designed so next glyph overlaps previous one and that is why the whole text bounds width is less than expected.

I wonder if this is not something that should be done with kerning instead, I mean, advance should be the width of the glyph texture, but kerning should be defined to change how one glyph is positioned in relation to the previous one.

Could you help here @jsantos?

I understand what is going on here. The bounding box in the main thread is calculated using the 'advances' of the glyphs. This is done this way, and probaly the same reason WPF is doing the same, because in the main thread there is no information about rendering (so calculating the bounding box from the beziers could add extra overhead). But it seems a bug to me (both in Noesis and WPF) and with the extra problem that it is affecting our opacity algorithm (WPF seems to be doing this right) so the problem is worse than WPF.

I need to find an efficient solution for this.

Hi guys, has any progress been made on this issue? We've been appending spaces to strings to our strings for a while but we've just started implementing localisation and I'd like to see if we can fix this properly.

Much appreciated,

-Steven

Hi Steve, we still don't know how to solve this but thanks for the reminder. I am increasing the priority, there are a few ideas I want to try,

Hi Steve,

We tried adjusting the bounds with the real beziers, but we are not sure this is the right solution. There are scenarios, like for example a text that has normal and italic runs intermixed where the changes in the bounds doesn't look right. In fact, we tried WPF, UWP and HTML5 and all of them behaves the same about this (text is drawn out of the box).

Another approach is being able to "hack" a font by setting global modifiers to advance and kerning. Tweaking these values, we had a result that is probably valid, but we are not sure about how to expose this font hack (in the fontprovider?)

Probably we should have a quick talk about this if you have time.

Cheers Jésus, sure thing. We've got a milestone tomorrow so I'm a little busy this week, but I'll be free for a chat any time next week. We already override the font provider so allowing us to specify values there seems like a fine solution to me.

We are working on the optimization we talked the other day to automatically move single element Opacity to the draw commands without requiring an opacity group.
This will fix the problem you are seeing when animating the opacity of right aligned italic text that appears now clipped.
But we are thinking, why can't you just animate the Opacity of the Brush in those situations? It is exactly the same kind of animation, but instead of Opacity property, you will animate Foreground.Opacity (or whatever brush property you want to change). Isn't that a valid solution for now?

Implemented the optimization to avoid generating offscreen textures for single node opacity groups.
This will fix your problem when animating the Opacity of right-aligned italic TextBlocks.