TextMesh Pro LinkData containing a sprite reference breaks the display

Hello,

TextMeshPro does not display the following as expected:
<link="<sprite name="Holy"> spells perform better">Bolstered <sprite name="Holy"></link>

However, removing the nested sprite reference works as expected:
<link=" spells perform better">Bolstered <sprite name="Holy"></link>

I would expect TextMeshPro to not scrape or process the contents of the LinkData.

Am I wrong to assume this? Is there a work around?

Thank you
Les

 

The format of the link tag is as follows: <link="ID">text to be displayed</link>. The ID is used to identify the tag itself and should not be made up of other tags is this would most certainly confuse the parser but make that ID sort of unusable.

Is there a reason, you are referencing a sprite in the ID?

 

Hello,

This is being used to implement hyperlinks, tooltips, error message popups, etc. I have a generic system that acts a middle man. It is merely provided with LinkID to associate to a block of Ui text. On hover and / or click of the Ui text block, the data LinkID is provided to the client.

IE my code doesn't care what is inside of LinkID.

I am not sure why TextMeshPro cares what is inside of LinkID either.

My reference points were

and
https://deltadreamgames.com/unity-tmp-hyperlinks/
Both of which seemed to suggest to me that LinkID was generic data to be used as I want.

Did I misunderstand the API?

Thank you for your assistance. I appreciate it.
Les

 

The issue occurs as a result of the link ID containing a tag which causes parsing issues. The link ID itself should not contain a tag.

Since the link ID is hidden data and never displayed, there is no reason / use case that I am aware of for it to contain another tag or to even be something other than a simple type like an INT used for quick lookup in some Dictionary or something to identify the content of the link.

Any reason you are referencing a sprite in the link ID itself?

 

Hello,

I must not be doing a very good job of explaining myself. I apologize for that.

That being said, it is now clear to me how to work within your system. Thank you for clarifying it.

It probably doesn't matter for the rest of this conversation. But, if you are still interested as to what I was trying to convey ....

My point is that your code should not be putting any limitations on the LinkID contents.
Your code should not care what is in there.
Your code should not parse the contents of LinkID at all.

What if the client code just has some string data from a network packet, and it is to be associated with LinkID?
The contents of LinkID could be representing anything.

Instead, the client code has to create it's own look up table now; some sort of data to id mapper.
It seems like this would not be necessary if your code was not trying to parse the contents of LinkID.

Possibly I am oversimplifying the process? Maybe it is difficult for some reason?

Either way.
Thank you for this feature and this great tool. And thank you for explaining how I need to use the feature.
Lester

 

Although I could re-work the handling of the Link ID to ignore potential nested tags, for performance reasons, limiting the length of tag names, values, number of attributes / overall complexity in the parsing is best.

This Link ID should not be used as data storage for the content of the link as having to parse through an additional 50 to 100 or more characters to determine if we have a valid tag and ID (as I have seen many times) impacts performance which can be avoided by keeping the ID short with some lookup where this ID can end up referencing link content of any length with marginal if any performance impact.

I recognize that many users will intuitively assume this Link ID is equal to Link Content which it is not / should not for the reasons stated above. I am not opposed to adding additional logic to the parsing of the link ID if the current implementation limits desired functionality.

Currently the Link ID can sort of be used as Link Content provided this ID is of less than 120 characters and does not contain other tags. I still do not recommend using the Link ID in this fashion. It will work but is not as efficient as using an INT for ID with lookup in your own data structure.

 

Hello,

All I am saying is that LinkId, in my opinion, should be treated as nothing more then a data blob.

And, I don't think your code should be concerned about it's contents.

I feel like this thread is starting to pick on you, though. And that is not my intent. I really do enjoy TextMeshPro, and I appreciate the work you have done on it.

All the best
Les

 

Understood. In order for it to be just a data blob, it potentially means more characters to parse thus impacting performance and heavier data structure.

Understood but the parser still needs to figure out the tag, if it is correctly formatted, if its value is valid and where it potentially end and store this content for lookup if needed.

No worries here You are providing feedback on a feature / implementation. I am trying to get a clearer understanding of your needs and potential concerns about the current implementation / trade offs. In the end, I want to make sure the tool does what you need it to do (if possible of course).

In this particular case, I am just trying to correctly convey the trade offs between a simple Link ID with limited complexity and fewer characters to read / parse vs. a potentially more complex data blob and how it would impact parsing performance and to have you (the users of the tool) provide feedback on whether the added functionality is still desirable enough to warrant the potential added overhead.

Here is an example to try to better illustrate the added complexities in this. Given the following:
"<link="Some long content data blob of 150 characters ... that contains <color=#00FF00> ... with more stuff ... and eventually the end of the tag">"

When the parser encounters the first "<" it reads the subsequent characters and efficiently identifies the tag as a potential link tag. It keeps reading subsequent characters to figure out if we have a valid tag in terms of the name, value (ID here), correctly formatted and where it ends.

With something like "<link="ID01">Some text to display</link> This is pretty simple even if the user doesn't use quotes as required to enclose the ID.

But with the previous example, how does the parser know ">" in the character sequence of <color=#00FF00> is not the end of the link tag? Does it now have to validate this other tag too? Does it end the tag at the first encounter of ">"? Does it rely on quotes which could be contained in this content too? What if the user omits the quotes? Does it potentially read all the way to the end of the text before it concludes the tag is not valid? Suddenly, the logic becomes more complex with a lot more characters having to be read / parsed and iterated over.

I am not saying this functionality cannot be supported. Just want to make sure we keep the costs of this added functionality in mind vs the alternative of using a simple Link ID that requires an additional data structure / lookup on your end but enables this Link Content to be of any length and complexity without any performance impact or added overhead to the parsing of the text.

How crucial is this new functionality for your needs?

 

It seems to me that the parser would behave like this:

1) Encounters the first <
2) Knows that is the start of a tag
3) Continues to read to determine what the tag type is
4) Encounters link="
5) Knows that is the start of the Link ID
6) Continues to blindly read until the closing "
7) No parsing would be applied to the characters being read during step 6

As for how to handle an extra " within the Link ID block itself? Luckily that is a problem that has existed for decades within programming, and a fairly good standard has been agreed upon already. \" would denote a quote that should be ignored by the parser. As per https://docs.microsoft.com/en-us/do...put-quotation-marks-in-a-string-windows-forms

I am unclear what this means. I don't understand why the parser needs to see if Link ID is correctly formatted, and if it's value is valid. Actually, I don't understand how the parser can ever dictate what is valid Link ID or not. I guess this is the fundamental part that keeps confusing me. Why should the parser ever care what is within Link ID? Also, what does "where it potentially end and store this content for lookup if needed" mean?

Correct. But, I would also argue that this it should be up to the client code if this cost it worth it or not.

Who is to say what amount of parsing is acceptable or not? A mobile game 5 years ago is going to have different opinions then a AAA PC game in 3 years. Maybe the client code isn't even a game; maybe its pre-rendered movie clip. Your code is going to be used by a huge range of products for many years to come.

Finally, it's always going to be possible for clients to create bad code with your tool. It's the nature of programming. Yes, a good API can help limit or prevent that. But, I would argue that this concern is not part of the feature's definition or scope.

I am glad to hear that. I really hope you don't feel like I am attacking your code. I am sorry if anything comes across that way. I was a buyer of TMP before you joined unity, and still use it in every product of mine. It's a fantastic tool.