This issue has come up a lot, but I don’t think I’ve seen anyone mention this specifically with non-roman characters.
We’ve attached a VisionOSSortingGroup to our UI elements, everything works fine in most languages. We see the cutout letter sort order rendering issue come back when we switch to Chinese, Japanese, Russian, Arabic, Korean.
Would these other characters cause it to ignore the sorting group somehow? Any workaround we can try? We tried changing our default font asset in TMP_Settings to NotoSans, a font with those characters included, but that didn’t have any effect. We tried changing those TMP text items to use NotoSans as well, and it seems like different characters had the issue after swapping font, but still had the issue across the board.
Video: character_sort_order_cutouts.mov - Google Drive
Yeah, the issue is that TextMeshPro creates a new (child) component for the characters outside the font, and that component’s CanvasRenderer isn’t being included in the Sorting Group list:
Perhaps a dumb question, but have you tried using the Apply to Descendants option in the sorting group? If you have, it’s entirely possible that it simply isn’t picking up the new descendant if it’s added after the sorting group is initialized. That’s something we will have to fix. It would help if you could submit a bug report with a repro case and let us know the incident number (IN-#####), if that’s possible.
In the meantime, one possible solution would be to recreate/update the sorting group component(s) after switching languages (and either use the ApplyToDescendants option or explicitly include the SubMeshUI CanvasRenderers in the list). Note that if you update them, you have to actually set the renderers property (if you modify the list without setting the property, the sorting group component won’t be marked as dirty).
I’m not sure why using a font with the characters included doesn’t work. Does it still create a SubMeshUI component when you switch languages in the editor?
Thank you @AndrzejUnity, that is exactly what it was. We did not have Apply to Descendants set on any of our items in the sorting group.
This did get a little more complicated than just setting those TextMeshPro items to Apply to Descendants. Because our UI is a blend of different types of renderers, we’ve ended up creating an “auto” sorter to just grab all child renderers and set their sorting groups based on their z position. That worked great, and almost worked, just didn’t work in this case because the child submeshes are created after the group has been initialized, which is why this issue was happening. We tried to set any that had TextMeshPro components to applyToDescendants in that auto sorter, but a lot of our views have gameobjects disabled so we can play a transition animation enabling and scaling objects in when shown. It seems TextMeshPro doesn’t create those child submesh items until the gameobject is enabled, which makes sense, but that means we had to just be careful with our timing of when we set that renderer list in the sorting group. It’s like you said, new descendants aren’t being added to the sorting group after the group has been initialized.
We will definitely work on getting this fixed for a future release. Thanks for the heads-up!
