TextMesh Pro Auto Wrapping Ellipsis causing TMP_TextUtilities.FindIntersectingLink to return wrong value

Hello dear friends,

I apologize if this is something that has been covered before but I couldn't find a proper answer for it.

I have been using the Link feature successfully for a while now but I seem to have stumbled into an issue I can't figure out how to workaround so far.

The issue is: on a TextMeshProUGUI, when the options Wrapping & Overflow "Enabled" and "Ellipsis" and having the text long enough to cause the auto ellipsis to show up. The links index look up no longer works and always returns -1 instead of the proper link index. As in the example below:

Code (CSharp):

1. int linkIndex = TMP_TextUtilities.FindIntersectingLink(text, Input.mousePosition, null);

For example, in a TextMeshProUGUI with its RectTransform size to fit only the word "Test" with the content:

<link=guild>Test</link>

works fine
But as soon as I increase the text size to cause ellipsis it no longer works, example:

<link=guild>TestTest</link>

Thanks in advance for the help.

 

The way Ellipsis or Truncate is implemented results in the parsing text being truncated which likely results in the closing <link> tag being ignored.

This is something I'll need to look at. Right now I am focused on getting the next TMP package released so it might have to wait until then. I'll provide an update here once I have more information to share.

 

Thank you for replying.

Would it be possible to provide which method checks for ellipsis on tmp side so I can do that manually and shorten the contents of the link when it reaches the size limit?
This should be a workaround while we wait for a built in fix.

 

Handling of the overflow is in #region Check Vertical Bounds & Auto-Sizing

But addressing this will be tricky and require I figure out a different way to handle the vertical overflow.

The challenge is as follows: Assume you have lots of text that contain lots of rich text tags. Now assume we truncate the text after the first line, then do we still process / worry about all the potential subsequent tags for all the truncated text?

I need to think about a clean / nice way to handle this.

Edit - The link tag is pretty much the only tag where it is processed in the closing part. Ie. without knowledge of the closing part, there is no way to know where it ends. But given it is the only tag that behaves this way, maybe that makes it easier to handle in some special way. (thinking out loud)

 

Thanks for the reply, I actually got a bit lost in it but in the end I was able to come up with a local solution that will probably only work for my case and only in a few areas. Here is the code sample just in case. If you have any suggestions on something I might have overlooked that would be welcome.

Code (CSharp):

1.  
2. private bool EllipsisLinkFix(TextMeshProUGUI tmp)
3. {
4.     string closingText = "</link></u>";
5.     if (tmp == null || !tmp.enableWordWrapping || tmp.overflowMode != TextOverflowModes.Ellipsis || tmp.text.Length < 5 || !tmp.isTextTruncated || !tmp.text.EndsWith(closingText))
6.         return false;
7.  
8.     string localText = tmp.text+"...";
9.     for (int i = localText.Length-((closingText+"...").Length); i > 0; i--)
10.     {
11.         tmp.ForceMeshUpdate();
12.         if (!tmp.isTextTruncated)
13.             break;
14.         localText = localText.Substring(0, i) + closingText + "...";
15.         tmp.text = localText;
16.     }
17.  
18.     tmp.text = localText.Replace(closingText+"...", "..."+ closingText);
19.     return true;
20. }
21.  

 

We're on 3.0.6 and still having this issue.

our solution is to lazily change the string if it's over a certain amount of characters, add the tags to the string after.