3.0 and UILabel Scaling

[Ferazel]

I thought I'd create a new topic for this since this appears to be a problem some other people are having and we can discuss how to fix this.

I upgraded to 3.0 since I have some time now to get this project updated. However, there appears to be a change in process or functionality in regards to UILabel scaling. Currently there is a width/height of a label area and there are 4 separate options in regards to label scaling.

Shrink Content - Will shrink the contents based on the height of the widget. Useful for reducing size of the content for dynamic areas.
Clamp Content - Will remove any characters that do not fit within the area of the widget. Useful for clipping extra content for dynamic content.
Resize Freely - Will resize the width/height of the widget to fit the contents. Useful for static text.
Resize Height - Will resize the height of the widget to fit the contents. Useful for dynamic multi-line areas.

The problem that I and other people have been using the scale property on a (pre 3.0) UILabel to actually change the size of the text reducing the content size of the widget. My feeling is that Shrink Content would have a static width/size widget size and will auto-scale the content to fit that. Currently, in NGUI 3.0 it only appears to affect when the height is a problem not the width.

Edit: I should mention that I'm using a dynamic font not a bitmap font for the UILabels.

[ArenMook]

You need to set max lines to 0. Don't use that parameter anymore.

[Ferazel]

Thanks for the response, but that isn't the problem that I'm encountering.

If I set the line count to 0, the UIFont.WrapText will just create an infinite number of lines. This is not the desired behavior. I need to set a static widget size that the contents will scale in both the height and the width in order to fit that widget's width and height.

From my digging so far, shrink content is ignoring is ignoring if the text actually fits the width or not. It only triggers on height doesn't fit because the maxLines is 0 if the height of the font is too large. The problem appears to be that UIFont.WrapText is returning true that the text fit even if it needed to truncate the text. Which is causing the following line to never execute thus reducing the size of the font if it is the width that doesn't fit
else if (mOverflow == Overflow.ShrinkContent && !fits)

Edit: One problem is that this in UIFont.WrapText() is returning true using this logic:
return (!multiline || offset == textLength || (maxLines > 0 && lineCount <= maxLines));
So regardless of how many lines actually were rendered if there is 1 line (multiline is false) it will always assume that the text fit. This isn't the only problem though, but one of them I feel.

[ArenMook]

If you want it to scale the way you showed, change its height to something smaller. Make it 1 line tall, and there you go, it won't create any additional lines for you.

If you give it space, it will use it.

[NaxIonz]

While this shrink-to-fit is very hand, I would also like to point out that it is not as easy to make sure all the text is the same "font size." This is particularly true if you're trying to match one label that has 2 lines, and one that has a single line.

So far, I have found that I need to start off making sure (if it's a single line) I give it excess width, then slowly truncate it before it affects the size and starts shrinking it.

Back before you added this, I had wrapped your scaling system with this sort of logic:
-Supply a target scale that is ideal.
-Supply a minimun scale that is acceptable.
-Given our current scale, if everything fits given Y allowed lines, grow till we meet the target scale.
-Otherwise, if stuff does not fit, shrink till we hit the cutoff, at that point, truncate.

This gave designers the ability to say they wanted X lines (or not, it was optional), and also text would grow/shrink to fill the footprint while adhering to the min/max scales that were allowed.

--------

All that aside, in your new 3.0 system, maybe it would be nice to have a button that shrank the excess space away from the UILabel.
That way, we could defined a width that looked good, hit the shrink button, and that would make sure it didn't grow vertically if extra text wound up in there. Otherwise, you're setting the width, they entering new values into the height until you see it shrink, then you know you've gone 1 too far (which can be a bit tedious converting to 3.0 if you have what feels like 1,000 UILabels all over the place).

[NaxIonz]

Also, I am not sure if it is possible, but when using the handles, it would be nice if the anchor point could be set as the middle, then at least you're cutting the back & forth of scale the left, now the right, now the top, now the bottom, etc.

[Ferazel]

Changing the height on all of my labels to scale the font makes me sad. Personally, when I see a content setting called "Shrink Content" it would be a shrink-to-fit mechanic where the UILabel will scale the print size to display the content as a size that can fit in the width and height of the widget. I understand this behavior was not how NGUI <3.0 worked in regards to this scaling, but I honestly didn't use it that much because I could more easily change the scale of the label. Especially with multiple UILabels, the multi-edit function of the Transform was more useful. Now I need to change them all manually which is a workflow degradation.

Hopefully, shrink-to-fit and/or multi-editing UILabels can be something that can be added in the future to help.

[mishaps]

With 3.0, after talking with aren, I switched to dynamic fonts and have been making a new ngui-font for each "font size" I want and converting all my labels to scale of 1. Its time-consuming but I guess it does lead nice consistent font sizes...

I could totally go without using scale on labels if we could change the "font size" per-label instead of per-ngui-font. I guess it would be something like auto-generating it's own ngui-font in the background or something for each different font size. Dynamic-ngui-fonts, hehe heh.

[ArenMook]

Also, I am not sure if it is possible, but when using the handles, it would be nice if the anchor point could be set as the middle, then at least you're cutting the back & forth of scale the left, now the right, now the top, now the bottom, etc.

It works like that if you modify the "Dimensions" field in inspector instead of dragging the handles.

[Ferazel]

I feel that this is a step backwards from the control we had with setting the scale of the font, and is causing me to rethink how fonts would need to be handled in our game. Especially, in regards to high-dpi screens. Previously, halving the font scale to create a cleaner text on high-dpi devices. Granted you always wanted to balance the aliasing, but at least I could do that a per label basis rather than creating new UIFonts.

I'm curious on what other people are doing for their labels. Just setting the UIRoot fixed size to be retina at start?

[Yukichu]

Well, so far I've had to create 12 different fonts for different sizes / spacing.  It's different, for sure.

Weird behavior, upon 3.0 upgrade, multiline labels will not fit within their space correctly when using color coding.  It sees the color codes as space within the width of the line and wraps it.  It's easy to fix, and once it's fixed it doesn't reproduce, but it really threw me for a loop trying to figure out what was wrong at first.

One hand, the new system takes more setup.  On the other, once the fonts are all created, I like the feel of more absolute control over what it going on.  Just about done with a 3 hour upgrade.

[ArenMook]

Not sure how any of this is a step backwards. Forget the "max lines" parameter altogether, and it makes perfect sense. You specify the area the label can fill with the widget's width and height.

The way it was before -- max width and max lines -- that's what made no sense.

Also not sure what this has to do with different DPI devices. You increase the DPI by creating a higher res font -- for example 64 instead of 32, and at the same time setting the pixel size to half the amount -- in that example size 64 font would have pixel size of 0.5.

[mishaps]

yea step-backwards for me too my artists are going to be like what da hell u mean I can't scale labels?! Minor size changes were easy before - just tweak the scale. Now every single change you gotta go make a new font first it doesn't feel intuitive.

What about if u could add a number of sizes to the ngui-font, then choose them from a list on the label? at least that way you wouldn't have to re-link it everytime you wnted a different size.

NGUI wish-list: per-label dynamic fonts size

[ArenMook]

Eh? You can change the scale of labels. Why not?

[mishaps]

wasn't the idea we use dimensions now?