TextMesh Pro TMP Fallback font underline bug

Just came across a strange (and probably unintended?) behavior in TextMesh Pro. If a font asset doesn't have the ' _ ' (underscore) character, we can't use underline or strike-through with that font. That seems fine, certainly the asset needs some way to draw a straight line. The real problem comes in when that font has a fallback font that does contain the underscore character, we still can't use underline or strike-through.

Could that be a simple oversight of not checking fallback fonts for the existence of an underscore character when applying underline or strike-through formatting?

 

I do plan on revisiting (soon) how the Underline and Ellipsis characters are handled especially with the introduction of the new Dynamic SDF system.

TMP currently expects these characters / glyphs to be present in the Primary / font asset assigned to the text object. These are common characters that should be present in almost all font files so short term, you just need to make your primary has them.

In terms of revised handling, I think it makes sense for TMP to search through the fallbacks to locate those glyphs. On the flips side, I hate having to add / require these to be in more than one font asset especially that 99% of the time, they all look the same. Unfortunately, there are a few font files where these are stylized so ... yeah!

 

Thanks for the quick reply!

For now this isn't a big issue, we can easily work around it. Just wanted to report/share it in case you weren't aware of it.

Looking forward to the continued development and all the new features of TextMesh Pro. Keep up the great work!

 

Looks like this still happens.
I have font A and B. Font B is the fallback for font A.
If font A doesn't have a certain character it will pick that character from font B. The problem is that it breaks the underline. Here are some examples:

Both objects use the same font with the same fallback Chinese font.


Now I thought it was probably because the fallback Chinese font (font B) doesn't have an underscore or something. But if I just use the Chinese font instead of setting it as my fallback font. It works fine:


So somewhere in the fallback it breaks something and can't place normal underlines anymore

 

It looks to me like it uses the settings for the primary fonts underline (like the underline offset and thickness), but scales it to the fallback fonts size.

So if your fallback font is created with a much smaller sampling point size, than the primary font. It will scale the underlines (and strikethroughs) up inversely. So it here appears very low and very thick.

This will probably often happen to Chinese, Japanese, Korean etc. fonts because they contain many more characters and are because of space efficiency saved at a lower resolution.

A fix would be appreciated. For instance to use a glyph from the font as the underline, as this could alleviate the problem with fallback fonts.



Curiously you can set the strikethrough offset for each fallback font individually without problem. Although that uses the same thickness as the underline, and will also be thicker.

 

Thought I would give a more thorough example as well of the problem.

Here the pointsize of the latin characters is 101, while the hangul characters have a pointsize 30, this explains the thickness and offset difference between the underlines and strikethroughs. (the bug)

Interesting observation as svenvanh also showed, if all the characters are connected in one underline tag, or text field, the underline will all be of the fallback font pointsize but the primary font underline thickness and offset.

This connectedness is not the case for strikethrough where the thickness is the only thing that is incorrect. Only the thickness is scaled up inversely with the ratio of the primary font's pointsize and the fallback font's point size.

Again this could probably be fixed if they just had the fallback font use the underline offset and underline thickness described in the font asset of the fallback font.