Max Lines for UILabel is ignored?

[mcarriere]

Seems like the maxLines value for the UILabel is ignored, am I misunderstanding something here?

To clarify: I'm expecting it to truncate the extra line at this point, and keep the remaining text within the width. Right now, it simply contains the text within the width, but doesn't truncate the text.

To inappropriately tag a request on this, it would be nice if there were a few modes for the UILabel, if you could choose between word wrap up to the max lines, or shrinking to fit, or a combination of the two.

[ArenMook]

"Shrink to Fit" and # of line limiter don't mix. Shrink to Fit basically overwrites its behavior.

[jeldrez]

IMHO, I think (if it's possible) if you selected on "Shrink to Fit" should hide the Max Line option. It would be more understandable to the user.

[ArenMook]

Yes... or just do it properly where it will shrink based on Y, not just X.

[mcarriere]

Reviving this thread: Just wanted to say I've now tested both 2.6.2 and 2.6.3 and the current implementation breaks much of our text.

It seems like the max width is being supported by scaling the X, but aggressively adding line breaks whenever it can.

So if you have a font that is otherwise large, it will put a line break after every single character, and then scale that down to fit the max width.

It makes sense that getting Max Lines and Shrink To Fit to work together, but if I have shrink to fit on, you should be displaying the text as I formatted it to fit in the given area.

Example of the issue: http://d.pr/i/F139

[mcarriere]

This seems to be fixed when I change line 513 on UILabel.cs from this:

1. else if (mMaxLineWidth > 0)
2. {
3.         mProcessedText = mFont.WrapText(mText, mMaxLineWidth / scale, mShrinkToFit ? 0 : mMaxLineCount, mEncoding, mSymbols);
4. }
5.  

to this:

1. else if (!mShrinkToFit && mMaxLineWidth > 0)
2. {
3.         mProcessedText = mFont.WrapText(mText, mMaxLineWidth / scale, mShrinkToFit ? 0 : mMaxLineCount, mEncoding, mSymbols);
4. }

Also, somewhat unrelated: there's somewhat of a bug with the MaxWidth. I had a large font that, due to the scale of it's parent, ended up having a very small max width: I noticed that I was changing the max width between 8-10px and there was no change in the actual size of the font.

Ultimately, the scale for the font was 1.7, which due to line 544 on UILabel.cs:

1. scale = Mathf.Round(scale);

It was being kicked up to 2.0, and thus, appearing outside of the maxWidth that I desired. Changing Round to Floor fixed that discrepancy in that it will always make the font smaller than my max width, and never larger.

This seems like a much more attractive position to be in, if you definitely don't want any fonts jumping outside any UI.

[ArenMook]

In your case you were not specifying number of lines, leaving at unlimited -- so of course it kept taking advantage of that.

Max width is in pixels. 200 means 200 pixels wide. Although Floor may make sense. I'll add it and see how it behaves.

[mcarriere]

In UILabel::ProcessText(), if the label isn't a password, this is the next if statement that would hit:

1.  
2. else if (mMaxLineWidth > 0)
3. {
4.         mProcessedText = mFont.WrapText(mText, mMaxLineWidth / scale, mShrinkToFit ? 0 : mMaxLineCount, mEncoding, mSymbols);
5. }
6.  
7.  

Since I've got ShrinkToFit set to true, this will force me to 0 regardless of what I put in, and will force the linebreaks, causing the long column of text I showed. Perhaps I'm not explaining myself correctly -- it just seems like there's a discrepancy in the UI, or what's being made available to the user that makes controlling how we want the text to wrap / fit to an area very error prone on the user side.