UILabel - ProcessText and UITable

[KyleStaves]

Hello,

First let me say I'm loving 3.0 so far. A lot of really, really awesome changes came through. However, I'm having an issue I can't seem to find the 'correct' way to solve. I have several situations where I am updating the text of a Label and then immediately resizing a UITable that contains the label. On 2.7.0 this worked fine, however - since moving to 3.0 it does not accurately resize any longer. The problem seems to be that I need to call "ProcessText" before resizing the lable. I can force this by accessing various values - but it would really be ideal if I could just directly call ProcessText() by making it public.

This is a super easy 'edit' for me to maintain, but I thought I would post just in case I'm missing something obvious. MakePixelPerfect isn't a good resolution because it also seems to be changing the dimensions of the label (one is set to "ResizeHeight" only and MakePixelPerfect is adding width to it, where as ProcessText works as expected).

Thanks for any feedback/input!

Best,
Kyle

[KyleStaves]

Unrelated issue, but I'm also curious if there is any reason the Y centering of fonts is not rounded to a pixel border?

With certain font sizes pixel perfection is broken depending on how many lines are rendered (usually an odd number == pixel perfect, even number == not pixel perfect).

I can easily resolve this on my end at line 774 of UILabel (in 3.0.1) and changing:

1. // Center vertically
2. fy += Mathf.Lerp(mSize.y * scale - mHeight, 0f, po.y);
3.  

to

1. // Center vertically
2. fy += Mathf.Lerp(mSize.y * scale - mHeight, 0f, po.y);
3. fy = Mathf.Round(fy);
4.  

Is there any reason I shouldn't do this?

[ArenMook]

The original topic's proper fix is to have the label override localCorners and worldCorners functions and process text inside. This will fix the widget dimension calculations.

Your second post... I'm not sure about that one. Where is it becoming non-pixel perfect? I need repro steps with an example before changing this part of the code.

[KyleStaves]

Thanks for the quick response!

I'm attaching a font that allows for easy reproduction of this. It seems to vary based on the specific font (sometimes it works fine, sometimes every even line breaks pixel perfect, sometimes every odd line breaks pixel perfect).

Reproduction is very easy, just create a centered label in an empty scene and write a few lines. You should notice with this font that every other line breaks pixel perfection. I'm also attaching screenshots of what it looks like.

EDIT:
The issue seems to be caused by an odd value in "mHeight" - rounding it like above fixes the issue, but perhaps a better fix is to enforce not only an int mHeight, but an even int mHeight when it's getting set?

[ArenMook]

Can't reproduce it on my end. I created a font using the files you specified, and I can't get it to be blurry. In fact, NGUI won't even let me use an odd value for height unless I manually enter it. When dragging the handles of a centered label, it always forces the height to be even. Manually entering an odd value doesn't break it either, everything remains crisp.

[KyleStaves]

Just wanted to bump this up to share the actual problem I was having. Since ArenMook couldn't reproduce the issue with the exact same font it dawned on me that the problem very well could be caused by our setup of that font.

We had the "spacing" of the font in the settings for it set to 0,3. Having an odd spacing along the vertical is what was breaking it on every other line. I don't think it's worth disallowing odd spacings at all since they're definitely used and useful in certain situations - but just be careful that they can break pixel perfection in other situations.

Thanks for helping me resolve this ArenMook! Excellent support as always.