ContentSizeFitter has incorrect height when TextMesh Pro Wrapping is enabled

Unity 2019.1.10f1
Unity 2019.1.12f1
Unity 2019.2.0f1

Content height is incorrect


The following settings have been made to GameObject.

ContentSizeFitter
Horizontal Fit - Unconstrained
Vertical Fit - Preferred Size

RectTransform param
Width 400
Text Mesh Pro UGUI
Text↓

Code (CSharp):

1. SystemInfo = {
2.     batteryLevel = -1,
3.     batteryStatus = Charging,
4.     copyTextureSupport = Basic, Copy3D, DifferentTypes, TextureToRT, RTToTexture,
5.     deviceModel = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX,
6.     deviceName = XXXXXXXX,
7.     deviceType = XXXXXXXX,
8.     deviceUniqueIdentifier = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx,
9.     graphicsDeviceID = 7298,
10.     graphicsDeviceName = NVIDIA GeForce GTX 1050 Ti,
11.     graphicsDeviceType = Direct3D11,
12.     graphicsDeviceVendor = NVIDIA,
13.     graphicsDeviceVendorID = 4318,
14.     graphicsDeviceVersion = Direct3D 11.0 [level 11.1],
15.     graphicsMemorySize = 4018,
16.     graphicsMultiThreaded = True,
17.     graphicsShaderLevel = 50,
18.     graphicsUVStartsAtTop = True,
19.     hasDynamicUniformArrayIndexingInFragmentShaders = True,
20.     hasHiddenSurfaceRemovalOnGPU = False,
21.     maxCubemapSize = 16384,
22.     maxTextureSize = 16384,
23.     minConstantBufferOffsetAlignment = False,
24.     npotSupport = Full,
25.     operatingSystem = Windows 10  (10.0.0) 64bit,
26.     operatingSystemFamily = Windows,
27.     processorCount = 8,
28.     processorFrequency = 4200,
29.     processorType = Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz,
30. }
31.  

Is there a way to get the correct size?

 

I just tested the above with the same settings and got the correct results.

I tested in both Unity 2018.4 with TMP version 1.4.1 and Unity 2019.1 with TMP version 2.0.1.



Going to install the latest release of 2019.1 to see if I get a different result.

Update
Just re-tested in Unity 2019.1.12f1 with version 2.0.1 and also got the correct results.

Looking more carefully at your screenshot, the Text in the Text Input Box appears to be formatted differently.



See how the word "batterLevel = -1" is aligned pretty close to the left margin whereas in your screenshot, the text appears to be tabulated differently. Perhaps there are some control characters in there which got filtered in the text your pasted in this post?

Are you using a Tab in the text?

Update #2
I believe that is the source of the issue. The Tab character appears to be messing up the preferred height calculations. In the copy / paste of the text, the tab was converted into 5 spaces whereas your original text contains a tab on each line.

I'll take a closer look later this week to resolve this behavior with the tab. In the meantime, use the old trusty spaces.

 

The text entered for the first post used tab characters.
Converting tab characters to spaces now works correctly with Width 400.
Thank you for the information.

However, even if you use spaces, setting the width to 300 will generate margins.


Even if it is space, if the width of RectTransform is reduced, the height may not be correct.

 

The incorrect Preferred Width / Height calculations when using Tabs is / was a bug.

To resolve this issue, simple change the following line of code in the TMP_Text.cs as follows:

Code (csharp):

1.  
2. #region XAdvance, Tabulation & Stops
3. if (charCode == 9)
4. {
5.     // Change this line
6.     float tabSize = m_currentFontAsset.faceInfo.tabWidth * currentElementScale;
7.    
8.     // To the following
9.     float tabSize = m_currentFontAsset.m_FaceInfo.tabWidth * m_currentFontAsset.tabSize * currentElementScale;
10.  
11.     float tabs = Mathf.Ceil(m_xAdvance / tabSize) * tabSize;
12.     m_xAdvance = tabs > m_xAdvance ? tabs : m_xAdvance + tabSize;
13. }
14. ...
15.  

This change will be included in the next release of the TMP package.

I terms of the issue with spaces, this occurs when the width of the text container is smaller than the longest word which in this case are those xxxxxxxxx sequences.

 

>This change will be included in the next release of the TMP package.

I understood the tab character problem described in your last message.

>I terms of the issue with spaces, this occurs when the width of the text container is smaller which than the longest word in this case are those xxxxxxxxx sequences.

Margin that occurred in xxxxxxxxx, but it seems to be fine with UI.Text.


Will the "TextMesh Pro UGUI" not have the same behavior?

 

UI.Text and TextMesh Pro are completely different systems.

The incorrect preferred width calculation when word wrapping is not longer possible in conjunction of tabulation or using many spaces will be resolved in the next release of the TMP package.

If possible, I'll post a solution / code change for that as well.

 

Noted with thanks.

The TMP package will wait for the update.

 

BTW: The Tab issue which you can resolve now with the change I provided, does affect normal layout.

However, the space issue which again only occurs when word wrapping is no longer possible and individual words need to be broken up by character is an unlikely scenario as it make the visual layout of the text kind of bad which most designers would avoid.

So my suggestion is to make the tab change and then keep on working as the spacing issue should not affect the project.

 

It is used for the function to display the character information input by the user like chat.
Also, the display area can be changed by the user.

Tab and space input depend on user input
The condition was that the size of the content was calculated correctly under any conditions.

At the moment I was using UI.Text, but I was trying to change to TextMeshPro if there was no problem with the operation.

I was testing changes to TextMeshPro
Because the behavior of the content size might be wrong
I have contacted you.