Annoying message "Auto Size Iteration Count: 100. Final Point Size..."

Hello!

Please add a function to disable the message "Auto Size Iteration Count: 100. Final Point Size..."

Thanks in advance

[quote=“denis_bogdanov”, post:1, topic: 877144]
Hello!

Please add a function to disable the message “Auto Size Iteration Count: 100. Final Point Size…”

Thanks in advance
[/quote]

What version of the TMP package are you using?

This message should not be displayed.

[quote=“Stephan_B”, post:2, topic: 877144]
What version of the TMP package are you using?

This message should not be displayed.
[/quote]

“com.unity.textmeshpro”: “3.0.6” [Verified]

I had a chance to look into this and this message is displayed when the iteration count exceeds 100.

We actually do not want to suppress this message as this is indicative of some potential issue with regards to the values you are using as typically iteration count should be between 8 -12. The higher the iteration count the higher the performance overhead so we want to figure out what is going on here to get this back to a normal range.

Can you post an image of the values you are using for point size and the min and max range?

1 Like

[quote=“Stephan_B”, post:4, topic: 877144]
I had a chance to look into this and this message is displayed when the iteration count exceeds 100.

We actually do not want to suppress this message as this is indicative of some potential issue with regards to the values you are using as typically iteration count should be between 8 -12. The higher the iteration count the higher the performance overhead so we want to figure out what is going on here to get this back to a normal range.

Can you post an image of the values you are using for point size and the min and max range?
[/quote]

I will describe the problem and how I solved it. But a little later, when I’m free.

[quote=“Stephan_B”, post:4, topic: 877144]
I had a chance to look into this and this message is displayed when the iteration count exceeds 100.

We actually do not want to suppress this message as this is indicative of some potential issue with regards to the values you are using as typically iteration count should be between 8 -12. The higher the iteration count the higher the performance overhead so we want to figure out what is going on here to get this back to a normal range.

Can you post an image of the values you are using for point size and the min and max range?
[/quote]

Hello!

I did the bottom bar. Text with “overflow” = "Ellipsis

Sequencings:

  1. Font size 45, all fine, but for Latin and Cyrillic characters…
    8032823--1035698--1.png

8032823--1035701--1a.png

  1. With Asian characters the text is not visible on some devices (it depends on the height of the component “TextMeshProUGUI”)
    8032823--1035704--Screenshot_2.png

  2. I enabled “AutoSize” min = 1; max = 45. But then “Ellipsis” doesn’t work

8032823--1035707--Screenshot_3.png

8032823--1035710--Screenshot_4.png

[quote=“Stephan_B”, post:4, topic: 877144]
I had a chance to look into this and this message is displayed when the iteration count exceeds 100.

We actually do not want to suppress this message as this is indicative of some potential issue with regards to the values you are using as typically iteration count should be between 8 -12. The higher the iteration count the higher the performance overhead so we want to figure out what is going on here to get this back to a normal range.

Can you post an image of the values you are using for point size and the min and max range?
[/quote]

  1. But if I set “WD%” = 0.5 everything works fine and with Asian characters
    8032823--1035710--Screenshot_4.png 8032826--1035716--Screenshot_5.png

  2. But now an annoying message “Auto Size Iteration Count: 100. Final Point Size…”

  3. I did this: “AutoSize” = false; “FontSize” = 45; “Overflow” = “Ellipsis” and added code and everything works fine and the message “Auto Size Iteration Count: 100. Final Point Size…” does not appear
    8032826--1035719--Screenshot_6.png

I would like to hear your comments, maybe I did something wrong

Thanks in advance

Since fonts come in all shapes and sizes, you may have to normalize some of the Face Info metrics of your Asian / fallback fonts to match those of your primary font asset.

For instance, NotoSans has an Ascent Line that is much higher than Liberation Sans. As such, if the text object's Overflow mode is set to Truncate or Ellipsis, it could result in those Asian characters being truncated because they don't fit in the given height of the text container.

To adjust / normalize the Face metrics, add the TMP_TextInfoDebugTool.cs script to one of your text components. This script is contained in the TMP Examples & Extras and will enable you to visualize those metrics.

Below is an example showing the difference between the Ascent and Descent lines between Liberation Sans and NotoSans CJK.

8040194--1037141--upload_2022-4-11_21-32-24.png

To normalized / adjust these metrics, simply select the font asset you are using for CJK text and adjust the Ascent and Descent lines to match those of your primary font asset which is Inter.

Below is an example of the same text as above but with adjust face metrics.

8040194--1037162--upload_2022-4-11_21-35-27.png

Also note that text alignment is based on these metrics. As such, when using top vertical alignment, the text would be positioned where the tallest ascender is align with the top of the RectTransform. If the first line of text first contained characters from Inter and then subsequently followed by some characters from NotoSans CJK, you would notice the text shifting down vertically as it would not be aligned with the taller Ascent line from NotoSans. This is another reason to normalized those metrics to avoid these potential shifts due to fonts having varying metrics.

Normalizing your font assets should stop the CJK characters from disappearing.

In terms of Auto Size and the iteration count, I suspect is it due in part with the above and a min value that is too small. I would recommend making sure that you use somewhat valid ranges which would be between 8 to some higher value.

Let me know if the above helps.

1 Like

[quote=“Stephan_B”, post:8, topic: 877144]
Since fonts come in all shapes and sizes, you may have to normalize some of the Face Info metrics of your Asian / fallback fonts to match those of your primary font asset.

For instance, NotoSans has an Ascent Line that is much higher than Liberation Sans. As such, if the text object’s Overflow mode is set to Truncate or Ellipsis, it could result in those Asian characters being truncated because they don’t fit in the given height of the text container.

To adjust / normalize the Face metrics, add the TMP_TextInfoDebugTool.cs script to one of your text components. This script is contained in the TMP Examples & Extras and will enable you to visualize those metrics.

Below is an example showing the difference between the Ascent and Descent lines between Liberation Sans and NotoSans CJK.

To normalized / adjust these metrics, simply select the font asset you are using for CJK text and adjust the Ascent and Descent lines to match those of your primary font asset which is Inter.

Below is an example of the same text as above but with adjust face metrics.

Also note that text alignment is based on these metrics. As such, when using top vertical alignment, the text would be positioned where the tallest ascender is align with the top of the RectTransform. If the first line of text first contained characters from Inter and then subsequently followed by some characters from NotoSans CJK, you would notice the text shifting down vertically as it would not be aligned with the taller Ascent line from NotoSans. This is another reason to normalized those metrics to avoid these potential shifts due to fonts having varying metrics.

Normalizing your font assets should stop the CJK characters from disappearing.

In terms of Auto Size and the iteration count, I suspect is it due in part with the above and a min value that is too small. I would recommend making sure that you use somewhat valid ranges which would be between 8 to some higher value.

Let me know if the above helps.
[/quote]

Thanks for the detailed answer.
I will take your advice

[quote=“Stephan_B”, post:4, topic: 877144]
We actually do not want to suppress this message as this is indicative of some potential issue with regards to the values you are using as typically iteration count should be between 8 -12.
[/quote]
Could you please then at least add affected GameObject name into log message, and specify this gameobject (or component) as last argument for Debug.Log() call? Because now it’s actually not much informative when it happens, as it just state that “somewhere in the project we have issues”. We need a way to find such problematic places and fix them.
Thank you.