TextMesh Pro voffset(em) not working(2.1.0-preview7)

voffset not working in preview7.

Reproduce: preview 7, 8(2.1.0/3.0.0)
Can not reproduce: preview 1, 3, 4, 5

TMP is a really great asset! Recently, I was updating Unity 2019.2 and I've got a few bugs in TMP.. but still I'm using it well Thanks.

 

I just tested in 2019.2 using Preview 8 with both TMP components and <voffset=1em> appears to be working as expected on my end.

For testing, I used the following "A<voffset=1em>B</voffset>C" and the point size of the text object is 30 which would offset the character by 30 pixels or 1 em from baseline to baseline.



Can you provide me with the text and settings that you are using that are not behaving correctly?

 

Thank you for a quick reply.

I also checked that "A<voffset=1em>B</voffset>C" is working fine.

However, "<voffset=1em>B</voffset>" is not working that I expected.


Figure1 - preview8(7) - "<voffset=1em>B</voffset>"


Figure2 - preview5(1/2/3/4) - "<voffset=1em>B</voffset>"

Thanks.

 

I guess the question is what do we expect in the above case when you only have a single character?

Top alignment for instance aligns the text where to tallest ascent line is against to top of the text container. As such in this case, the vertical alignment of this B doesn't change.

Do you have an example / use case of where in this case with a single character it is an issue?

P.S. The reason for the change in behavior is due to white spaces no longer affecting vertical line metrics which is more consistent with MS Word.

This is also more intuitive when using something like "<size=75%>AB</size>(LF)" where the height of the Line Feed is at 100% resulting in the text being top aligned to the taller but not visible LF.

 

I understand what you mean. But it's painful because the offset that I've been using over the years changed since preview7.

Here are some cases:

* We have a common text box and we're dynamically assembling text inside it. In this case, rich text feature is very powerful. We can draw various kinds of text without modifying the prefabs.
* Original text is "99<voffset=1em>10% discount</voffset>", but in some cases, we can split texts for programmatic reasons. Some times, '10% discount' text can be changed a sprite.

Anyway, if you think it is not a bug and you don't have any plan to fix it. Let me know because of then we have to fix our sides.

In the short term, we are also considering how to make a hotfix. Now I'm watching diff between preview5/7. I hope I can get some advice. I'm looking at the TMP_Text.cs over 5541/5670~ lines and TMP_Private.cs 2296~ lines.

Thanks.

 

Let me go back and compare the behavior in previous releases to the new release.

Can you post a real example of how it used to look and now? Just so I have some real world looking reference and know exactly what to expect as using "99<voffset=1em>10% discount</voffset>" results in the following where the offset is correct but that certainly look wierd.

Using Preview 8


Using Preview 4

 

Yes, we want to show exactly the same after upgrading TMP.

This is our popup.

using preview1


The item can be anything. In this case, an item is 1 spin.

using preview7


Offset does not apply even over 12em.

In "99<voffset=1em>10% discount</voffset>" case, we have two TextMeshProUGUI components:
- "99"
- "<voffset=1em>10% discount</voffset>"
For example, discount labels are only visible during the discount period.

 

I'll take another look to see if I can make the behavior the same as before with <voffset>

I tested with 12em and 13em and the offset is correct other than the initial issue when the offset is applied to the entire line.

12em in your example would be an offset of 12 * 60 point size = 720 pixels.

 

I mean voffset has no effect when used alone.

"<voffset=1em>A</voffset>B" // case1 - It is okay.
"<voffset=1em>A</voffset>" // case2 - voffset has no effect

So, you mean if the voffset is used alone, the baseline becomes itself, no matter how much the voffset is. Right?

I'm a little bit confused but now I understand the relationship between voffset and baseline.. orz

 

"<voffset=1em>A</voffset>B"
or
""<voffset=1em>A</voffset>"

The above two examples behave exactly the same in Preview 1 and Preview 8. Are you see a difference on your end?

In the case of "<voffset=1em>A</voffset>", the reason it doesn't appear to work is simply because top alignment aligns to tallest Ascender with the top of the RectTransform. Since the letter A regardless of the offset will always be the tallest, it is always aligned the same way.

Can you provide me with a simple repro of a scene that works correctly in Preview 1 but is incorrect in Preview 8?

 

I have attached a simple sample.

1. Open Assets/Samples/SampleScene.unity.
2. Setup Text(Canvas/Text 1 - Alone).
3. Take screenshot 1.
4. Change TMP preview8 to preview1
5. Take screenshot 2.

screenshot1 - preview8

screenshot2 - preview1


I was set vertical alignment 'middle'.

 

Thank you for providing the repro project.

I finally got a chance to look at this again. The issue is visible when using vertical alignment other than top.

The change in behavior is related to how the descender of a given line is tracked.

In previous versions like Preview 1, the descender wasn't tracked correctly where in the case of using a positive offset, this value remained uninitialized at zero instead of some positive value reflective of where the character's descender ends up above 0 which is the baseline. As such, it ended up using a descender value of 0. In Preview 8 for example, the descender is tracked correctly where in this case we end up with some positive value which is why the vertical alignment is different.

The question now is how to handle this...

Here is how alignment in Preview 8 when using <voffset=1em>

Top Alignment where highest Ascender is aligned with top of text container.


Center vertical alignment which uses the highest Ascender and lowest Descender and aligns the text in the middle vertically.


Bottom Alignment where lowest Descender is aligned with bottom of text container.


As you can see it is correctly aligned in Preview 8.

In Preview 1, with middle vertical alignment we were getting the following which used the correct Ascender with voffset but used 0 as the Descender instead of the actual descender of the offset letter A.


In terms of a potential revised behavior when using voffset, I could make it such that voffset would use the Descender of the current font and size which would be the same / consistent whether you have a single character using voffset or not on a line. Unfortunately, this would still result in a different position then in Preview 1 but it would be closer in the sense of the different between baseline and descender position vs. the much larger shift of baseline to voffset adjusted descender.

Thoughts?