I did the naive thing to move voffset at the end of the string instead of the begin. It works in some cases, but not in another. This means I didn’t crack how voffset used to work in TextMesh Pro 2.0.1 and how is different from 3.0.3
please help
edit : it seems that when voffset is used with pixel values, it gives different results with 2.0.1 and 3.0.3. Did the unit reference change?
OK so after several hours investigating I realised that I cannot figure out on my own a way to revert to the old behaviour just parsing the string. I may be forced to actually revert the portion of code involved in the voffset logic hoping it would be neough
Changes were made to spacing which would affect voffset in the preview phase of 2.1, etc. This was done to make spacing more consistent. See the following thread related voffset which might provide some additional insight on this.
In terms of the voffset spacing, it is in pixels so assuming correct scaling of the camera, etc. a value of 3900 would be 3900 pixels which is massive. If you need the value to be relative to the point size of the text, then I would use an em value instead such as <voffset=1em> where assuming the point size is 100 would represent 100 pixels. if the point size was 50 than 1em would be 50 pixels.
Yeah the problem is that we are letting the users input text with tags for customization and they get there with trial and error. Using pixels is a mess and a slight change breaks everything
we literally let the users copy and paste tags, so I guess the second solution may be interesting. However I noticed that the problem wasn’t about the value, but the fact that the value seems to have a different scale between the two version of text mesh pro.
I didn’t get to the point where I understood what would cause the difference in scale. My limited understanding that could be wrong is that moving the voffset in such a way the result would be the same from before to after, would work only with em values, but not pixel values.
When I realised that, I stopped investigating and just made 2.0.1 work again, which luckily was just one line of code matter!
it would probably be extremely useful to have a conversion formula from pixel to em, so that we at least serialize the data only in em format. Do you have that?
The change with regards to handling of spacing values was necessary as the previous implementation was inconsistent and incorrect. There is no easy conversion since the inconsistency was due to how sampling point size vs text point size were handled.
Having said that, the tag value handling doesn’t seem affected contrary to my initial replies. As such, my apologies for the confusion. Please still note, this spacing change will affect spacing values in the inspector as well as tags like , which your users could end up running into but in this case, it is the other changes outlined in this thread that would be causing the change in behavior.
Now back to the main topic and figuring out if we are getting the desired / correct behavior.
The easiest way to understand the change is that now affects the baseline of the characters but not of the line.
Let’s take a look at a few examples to understand the difference between 2.0.1 and 2.1.3.
Given the following text “A<voffset=10>B”, we get the same behavior in 2.0.1 and 2.1.3. The letter “A” is positioned at the baseline and the “B” offset by 10.
If we now remove the letter “A” where the text is now “<voffset=10>B” we get the following results in 2.0.1 and 2.1.3.
In both cases, the letter “B” is offset by 10 but in 2.0.1, the line baseline shifted up as well whereas in 2.1.3, it remained unchanged. If we were to re-insert the letter “A” before the B or a space in 2.0.1, this would affect the line baseline but not in 2.1.3.
The above difference is important because, the subsequent line is positioned at the Descender of first line + line gap + ascender of subsequent line where in this case, the change in baseline between 2.0.1 and 2.1.3 produces the following results.
Given the following text:
“A<voffset=10>B
C”
Where we again insert the letter “A” before the tag, thus producing roughly the same results with the exception of the baseline of the second line shifting up since the letter “C” is first on the 2nd line. Ie. Same results as with the first line with or without the letter “A” before the tag.
Now, removing the letter “A” from the first line, gives us the following:
In 2.0.1, since the first line’s baseline and descender have shifted up resulting in the 2nd line and “C” being shifted up whereas in 2.1.3, the results remain consistent where the “C” is offset correctly above the line baseline which is also consistent whether the letter “A” is inserted above or not.
Basically, in 2.0.1, you would get different results whether you had a character at the start of the line before whereas in 2.1.3, that is no longer the case. In addition, in 2.0.1, you would get a different result if you had at the end of the line before a line feed or
because this line feed would be position on the line baseline just like when you have a letter at the start of the line. Now again, in 2.1.3, this is consistent as seen in the image below using the following text “<voffset=10>B
C”
This is most certainly a change in behavior, especially when your line of text starts with or ends with but it will now produce more consistent layout results and behavior.
Please note that a positive value can affect the max line ascender which will affect top vertical alignment as the text is aligned based on the top ascender of the first line. A negative can affect the max line descender which will affect bottom vertical alignment as it uses the lowest descender of the last line. These max line ascender and descender do ultimately affect line spacing.
Please help me understand how your users were using this tag and for what purpose?
I understood that the behaviour of the new text mesh pro was correct from my experiments. The problem is that we cannot use the new one as it will break our users previous generated. Our game is gamecraft. It’s a game that allows users to create games (ah!) through blocks.
one of these blocks is the Text Block. Modders started to create complex tool to use the block in unintended ways, like to create sprites.
You can see what I mean from this screenshot:
the easy text is a text block, but unexpectedly that big tapestry is also a text block. They use the voffset as trial and error mainly to find the correct vertical offset to match the environment
