The Teko font has had an issue since integration where the characters sit SLIGHTLY higher than the center of a TextLabel. This is an issue with a lot of the new fonts that were brought in, which was mentioned on the DevForum and was met with a response of essentially “work around it”.
In order to do so, I’ve had to drop all LineHeight properties from the default value of 1, to 0.9 in order to force my text to center itself without having to actually offset my TextLabel.
As of this morning, it appears that all of my TextLabels are offset to the top of the TextLabel again, and adjusting the LineHeight property does nothing.
Hello, thanks for reporting this! The recent changes to LineHeight are as intended as this fixed a previous bug with LineHeight that caused it to not measure text correctly and misalign the text. We do recognize that some fonts have different sized ascenders/descenders that cause them to look misaligned. We recommend adding UIPadding to your TextLabel instead as a workaround (see image example adding UIPadding PaddingTop). Sorry for the inconvenience! Let us know if you need anymore help with this issue.
Unfortunately UIPadding will not be a suitable workaround due to my entire user interface being built with AutoScaling instances paired with UIListLayout configurations that I performed tons of R&D on before I even began building out my components and style guide over a year ago. I made this approach as these horrible font metrics have been mentioned in the past, and were met with the response of essentially “find a workaround”. Now that I’ve found a workaround, the workarounds are being patched while the font metrics are just left.
This is extremely frustrating as I’m now going to have to do an entire pass on my user interface from start to finish and manually adjust over 1,000 TextLabel instances. Is there still no intention of adjusting any font metrics? Just checking so I’ve got a response to share around a year from now when my UI is decimated again due to contradictory updates.
The LineHeight fix is necessary as previously this was incorrectly calculating TextBounds that was breaking some UI. We have no intention of manually adjusting the font metrics themselves. We are releasing Engine Styling soon, which should make large changes to your UI system like this easier in the future. We are sorry about the inconvenience this causes.
Can you provide more specific values for what you did in this example, such as what padding values and AutomaticSize settings? Did adding top/bottom padding cause padding to increase on the left and right?
Atm I am just using 0.25 on top padding, as BungeeInline text sits at the top of TextLabel. I have AutomaticSize set to X, which with normal TextLabels would rescale based on text bounds, and would take into account LineHeight
Ahh, this is unfortunate, a lot of our UI in Jailbreak depends on the LuckiestGuy font which is offset & previously I was using LineHeight ~0.7 to correct it.
I thought at first this change was fixing the fact that LuckiestGuy is offset in the first place. It will be difficult to adjust all of the places in UI in Jailbreak to accommodate this change.
If a “breaking” change like this was made, it’d be nice if the actual ascender (?) of the font could be fixed, to double break it into the right configuration. If I were a new user, I would be quite confused why some fonts just look wrong. We’ve been having to do a jank workaround with LineHeight for years. Then I can just go adjust all my LineHeights to 1 as they properly should be. But not sure how feasible this is? @ThunderBolt5140
I tried recreating the example with a TextLabel with BungeeInline, TopPadding 0.25, 0 from UIPadding, and AutomaticSize X, but it seems to work okay when resizing the TextSize and text length. Can you send a placefile or script with your example to help us recreate the problem? You can also privately message the place if you prefer.
It is difficult for us to manually adjust the font file itself since this is how the font was created and licensed. Adjusting could cause other experiences to break, so we are not able to do this at this time. Sorry for the confusion and time needed to readjust your UI!
AutomaticSizeBug.rbxl (56.5 KB)
Can see with numbers, the padding on the edges gets larger the longer the text, which is not ideal. EDIT This seems to be an issue when TextScaled is true. When it’s true, the size of the container is being set to what it should be without the padding.
Thanks for reporting this! This is a bug where combining AutomaticSize with TextScaled and Padding is causing unintended spacing. We will try to prioritize a fix.
Is there any update on this? Still a huge issue for me
It’s like it gets to a max size and just stops, making text smaller over actually increasing the box size
We are still looking into this issue. There were some setbacks as a fix affected some other parts of the AutomaticSize pipeline, but this is still a known issue to address.
