View Issue Details

IDProjectCategoryView StatusLast Update
0001568NoesisGUIC++ SDKpublic2020-12-02 20:44
ReporterstevehAssigned Tosfernandez 
PriorityhighSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version2.2.1 
Target Version3.0.8Fixed in Version 
Summary0001568: Italic fonts have incorrect bounds
DescriptionHi guys,

We're having issues with the bounds of text being incorrectly calcualted with italic fonts. Interestingly, the behaviour demonstrated in Noesis is identical to Blend, so I'm guessing this is an issue with how WPF treats text.

I'm attaching a XAML document which can be loaded upo in the XAML Player to demonstrate the issue.

So it looks like the bounds for textblocks use the base of the text to calculate the bounds. Italic fonts clip outside these bounds. If we align the textblock to the right of the screen then the text goes over the edge of the container. If we force the text to be rendered offscreen by setting the opacity to a value other than 1.0 then when the offscreen texture is blended with the main back buffer the region is not correctly clipped and you see a hard edge. I understand why it's doing this, but it looks a little odd. I'm not sure on a good fix here.

Is there a workaround? If not, do you see this as requiring a fix since this pretty much behaves identically to how Blend handles italic fonts.

Cheers,

-Steven
Steps To Reproduce1. Create a textblock, add some text.
2. Set the font family to an italic font
3. Change the opacity on the text block to 0.5
4. Notice that the edge of the text is incorrectly clipped.

See my attached XAML document as a demonstration of this.
TagsNo tags attached.
PlatformAny

Activities

steveh

steveh

2019-10-14 13:53

reporter  

nebulari mono.otf (6,284 bytes)
Test.xaml (1,724 bytes)
sfernandez

sfernandez

2019-10-18 14:24

manager   ~0005998

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?
sfernandez

sfernandez

2019-10-18 14:26

manager  

italicbug.png (2,217 bytes)
italicbug.png (2,217 bytes)
jsantos

jsantos

2019-10-23 07:13

manager   ~0006000

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.
steveh

steveh

2020-10-23 15:39

reporter   ~0006700

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
jsantos

jsantos

2020-10-23 17:45

manager   ~0006701

Last edited: 2020-10-23 17:46

View 2 revisions

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,

jsantos

jsantos

2020-10-29 18:01

manager   ~0006711

Last edited: 2020-10-29 18:05

View 10 revisions

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.

steveh

steveh

2020-10-29 18:16

reporter   ~0006712

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.
sfernandez

sfernandez

2020-11-10 19:30

manager   ~0006720

Last edited: 2020-11-10 19:31

View 3 revisions

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?

sfernandez

sfernandez

2020-12-02 20:44

manager   ~0006857

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.

Issue History

Date Modified Username Field Change
2019-10-14 13:53 steveh New Issue
2019-10-14 13:53 steveh File Added: nebulari mono.otf
2019-10-14 13:53 steveh File Added: Test.xaml
2019-10-18 14:24 sfernandez Note Added: 0005998
2019-10-18 14:26 sfernandez File Added: italicbug.png
2019-10-23 07:10 jsantos Assigned To => jsantos
2019-10-23 07:10 jsantos Status new => assigned
2019-10-23 07:13 jsantos Note Added: 0006000
2020-10-23 15:39 steveh Note Added: 0006700
2020-10-23 17:45 jsantos Target Version => 3.0
2020-10-23 17:45 jsantos Description Updated View Revisions
2020-10-23 17:45 jsantos Steps to Reproduce Updated View Revisions
2020-10-23 17:45 jsantos Note Added: 0006701
2020-10-23 17:45 jsantos Priority normal => high
2020-10-23 17:46 jsantos Note Edited: 0006701 View Revisions
2020-10-29 17:14 jsantos Target Version 3.0 => 3.0.7
2020-10-29 17:57 jsantos Target Version 3.0.7 => 3.0
2020-10-29 18:01 jsantos Note Added: 0006711
2020-10-29 18:01 jsantos Status assigned => feedback
2020-10-29 18:01 jsantos Note Edited: 0006711 View Revisions
2020-10-29 18:02 jsantos Note Edited: 0006711 View Revisions
2020-10-29 18:02 jsantos Note Edited: 0006711 View Revisions
2020-10-29 18:03 jsantos Note Edited: 0006711 View Revisions
2020-10-29 18:03 jsantos Note Edited: 0006711 View Revisions
2020-10-29 18:04 jsantos Note Edited: 0006711 View Revisions
2020-10-29 18:04 jsantos Note Edited: 0006711 View Revisions
2020-10-29 18:04 jsantos Note Edited: 0006711 View Revisions
2020-10-29 18:05 jsantos Note Edited: 0006711 View Revisions
2020-10-29 18:16 steveh Note Added: 0006712
2020-10-29 18:16 steveh Status feedback => assigned
2020-11-10 16:54 jsantos Target Version 3.0 => 3.0.8
2020-11-10 18:57 jsantos Assigned To jsantos => sfernandez
2020-11-10 19:30 sfernandez Status assigned => feedback
2020-11-10 19:30 sfernandez Note Added: 0006720
2020-11-10 19:31 sfernandez Note Edited: 0006720 View Revisions
2020-11-10 19:31 sfernandez Note Edited: 0006720 View Revisions
2020-12-02 20:44 sfernandez Status feedback => resolved
2020-12-02 20:44 sfernandez Resolution open => fixed
2020-12-02 20:44 sfernandez Note Added: 0006857