Cut off and misplaced glyphs in static font assets with SDF/8/16/32

[osmoticstudios]

We have an issue that surfaced after we upgraded to TMP 1.4.0 and rebuilt all our font assets in preperation of localization for our game. I’ve so far been unable to pinpoint what’s wrong and I hope you can help me.

Here’s what’s happening:
Glyphs of some fonts get cut off at the sides or the glyph rectangle appears to be misplaced otherwise (i.e. too much whitespace around the actual glyph). This results in both cut-off characters and text that seems to move up and down between characters.

Example:
I’ve prepared an example where it is most apparant, using the Ubuntu font (Ubuntu Light in this case). Here is what the ‘S’ glyph and corresponding text look like when rendered with the following settings:

Ubuntu Light → Static (Extended ASCII), Point Size 50, Padding 5, Atlas 512*512, SDF16:


Note how the ‘S’ right side is cut off and the characters in the text seem to move up and down, not being placed on the same baseline.

However, these are the corresponding results using the exact same settings, but switching the asset to dynamic:

Ubuntu Light → Dynamic, Point Size 50, Padding 5, Atlas 512*512, SDF16:

Not only does the issue disappear, also note the difference in glyph rect width/height and glyph metrics. Unfortunately, we need to build static atlases rather than using dynamic ones, so switching to dynamic is not a possible workaround.

The issue remains observable regardless of atlas size, point size, padding, and across all SDF/8/16/32 render modes and affects many other fonts as well. Interestingly, SDFAA (both hinted and non-hinted) looks fine. Since we used SDF16 throughout our project before we’d like to maintain that render mode so our fonts keep the same visually.

If you have any idea what may be going wrong here, your help would be much appreciated. Thanks!

[Stephan_B]

Just to make sure I understand correctly.

Newly created font assets using SDF16 (with similar settings as above) appear incorrectly positioned?

I’ll take a look tomorrow and provide feedback shortly thereafter.

Update
Decided to quickly test this before going to sleep.

Top is SDF16 and bottom SDFAA. 50 Sampling point size with padding of 5.

Glyph metrics are identical (besides their position in the atlas).

I am seeing the cut-off. Using Extra Padding in the Extra Settings will get around this but this is something I need to look at.

I’ll look at it more closely tomorrow…

[osmoticstudios]

Thanks for the fast answer! Yes, this occurs with all new font assets and updated atlases created with any SD16 (or basically any SDF among 8/16/32). To exclude that this is somehow caused by our game, I created a new project from scratch.

With a font asset created in TMP 1.3.0 with SDF16, the text looks like this:

Then I updated TMP to 1.4.1 and re-built the font atlas of the asset with the same settings. Afterward it looked like this:

The characters have slightly moved up and down, though it’s not too noticable here. But the ‘S’ is clearly cut off and the same thing happens e.g. to the ‘.’ glyph.

To highlight the vertical displacement issue I tried the same thing with the font “Vollkorn Regular”:

In TMP 1.3.0:

In TMP 1.4.1:

[Stephan_B]

I can definitely see the issue with the legacy SDF modes (SDF16 and SDF32).

Until I resolve that, I would suggest using the SDFAA mode which still allows you to create static font assets. From a visual standpoint and at moderate on screen point sizes (anything smaller than 72+), you should not be able to see any difference.

I will be looking into this later today but suspect the required changes will be in the FontEngine which is part of the Unity Editor / Engine. Ie. not just a new TMP package.

[Stephan_B]

Here is an image showing SDF (no up-upsampling) vs. SDFAA Hinted. As you can see their metrics are identical and the positioning correct.

The shift occurs due to the up-sampling on SDF8 / SDF16 / SDF32 whereas the SDFAA modes do not up sample and are correct out of the gate.

[dlyttle]

I’ve noticed, what I think is, a related issue around the uneven text.

Row 1,2 and 3 are TMP all using Font (LiberationSans_SDF (TMP_FontAsset)) size 18.

Row 4 is normal non-TMP UI Text using Font (LiberationSans) at 18 points.

1, 2 and 3 only differ in placement and height of Rect Transform.

Note that row 3 looks fine in Game View but uneven in Scene View.

This happens with all sizes and permutations of Canvas size / transform size / placement / and font sizes. It is less noticeable with larger font sizes, but still happens. It is more noticeable with small font sizes

The only Font from the basic TMP supplied fonts that doesn’t exhibit this issue is the Electronic Highway Sign SDF font.

When you are sizing the text, or moving or sizing the transform you can see the letters ‘click’ into positions as if some rounding to an unseen grid is happening. The ‘m’ and ‘r’ appear to click at differing times than the other letters. It looked to me like they were actually slightly different heights – so that any rounding happened at a slightly different value for each.

I checked the glyphs in [Assets\TextMesh Pro\Resources\Fonts & Materials\LiberationSans SDF.asset] and found that the letters that showed shorter at times seemed to actually be shorter – at least judging by the ‘H’ values in their glyph info…

Is this a Font issue?

Would a different font than the basic TMP one’s supplied fix this (provided they don’t have different heights also).?

PS- using Unity 2019.1.4f1, was also happening on 2019.1.3

[dlyttle]

I just found - Character design standards - Lowercase for Latin 1 - Typography | Microsoft Learn

This seems to indicate that rounded characters as standard can overshoot a baseline and topline - thus they would have different heights. I tried adding lowercase ‘d’ and ‘b’ to my test setup and sure enough, they do behave oddly…

In both cases, its still the Liberty Sans SDF at 18 points. And the transfroms are the same width, but the height for the first is 45.55 and the second is 45.5.

[Stephan_B]

Thank you for the detailed report.

I’ll try taking a look at this next week or sooner if I can.

[dlyttle]

I think i’ve solved my own issue - all of the above were with a canvas Plane Distance of 0.3.
This leads to a ‘snapping’ within the editor - and seems to cause the text mesh to ‘click’ into awkward positions.

Once i set my canvas to the default 100 for Plane Distance, these artifacts largely vanish.
I tested at 0.2 and the issues were even worse. So this definately looks like my issue.

Sorry if i wasted your time.

[Stephan_B]

@dlyttle

I think i’ve solved my own issue - all of the above were with a canvas Plane Distance of 0.3.
This leads to a ‘snapping’ within the editor - and seems to cause the text mesh to ‘click’ into awkward positions.

Once i set my canvas to the default 100 for Plane Distance, these artifacts largely vanish.
I tested at 0.2 and the issues were even worse. So this definately looks like my issue.

Sorry if i wasted your time.

That is an interesting observation. I will need to look into that.

[wuhuan]

@Stephan_B

I can definitely see the issue with the legacy SDF modes (SDF16 and SDF32).

Until I resolve that, I would suggest using the SDFAA mode which still allows you to create static font assets. From a visual standpoint and at moderate on screen point sizes (anything smaller than 72+), you should not be able to see any difference.

I will be looking into this later today but suspect the required changes will be in the FontEngine which is part of the Unity Editor / Engine. Ie. not just a new TMP package.

Unity 2018.4.15 f1 textmeshpro@1.4.1 still a problem.

[Stephan_B]

@wuhuan

Unity 2018.4.15 f1 textmeshpro@1.4.1 still a problem.

PR is in flight to address this issue in 2018.4, 2019.3, 2020.x.

Version 1.4.1 is already pretty old (although the last verified version) release 1.5.0-preview.13 is the latest for Unity 2018.4.