MaxVisibleGraphemes not supported by AutomaticSize - add a toggle

As a Roblox developer, it is impossible to rely on MaxVisibleGraphemes to utilize AutomaticSize for gradually increasing text container sizes.

My use-case:
When utilizing a for loop to update text, it becomes impossible to use richtext without custom implementations. The first gif below shows how a textlabel will visibly scale when relying on

local text = "Hello, I am your host crash, welcome!"
textlabel.Size = Udim2.new(0, 0,  0.06, 0)
textlabel.AutomaticSize = Enum.AutomaticSize.X
textlabel.Text = ""
for start,bound in utf8.graphemes(text) do
	textlabel.Text = string.sub(text,1,bound)
	-- add 0.021 seconds worth of yielding
end

Because of this approach, Richtext needs to remain unnused.


:point_up_2: This resizing style is the desired effect of my usecase :point_up:

However, when implementing Roblox’ native Richtext feature, we cannot rely on string.sub because that will remove the Richtext rendering.

Instead, we need to rely on MaxVisibleGraphemes in order to keep the richtext in tact.

textlabel.Size = Udim2.new(0, 0,  0.06, 0)
textlabel.AutomaticSize = Enum.AutomaticSize.X
textlabel.MaxVisibleGraphemes = 0
--use a for loop to do textlabel.MaxVisibleGraphemes += 1
-- add 0.021 seconds worth of yielding

When approaching the issue with MaxVisibleGraphemes, the textlabel will scale like this, skipping the gradual UI size increase :



:point_up_2: This effect is not desired :point_up:

It has been pointed out on a thread previously:

If Roblox is able to address this issue, by adding a new property which makes AutomaticSize take MaxVisibleGraphemes into account by setting it to true for backwards compatibility, it would improve my development experience because: native UI behavior would be more consistent and I would not require workarounds for implementing richtext on dynamically scaling UI by using tons of custom code.

14 Likes

I think there’s some merit to this feature request, though I’d like to point out its bad UX to have text reflowing the way you’re asking for if you’re intending the text to be read.

It’s difficult, if not impossible, to read while it’s animating, which forces the player to slow down to wait for the animation to finish, which is almost always undesirable when working with animations. Players should never have to wait for an animation to finish in these kinds of scenarios.

3 Likes

Ever watched a movie with subtitles on, just to have a scene be spoiled by the captions because they were rendered earlier than the actual footage? My design choices stem from such frustrations and I believe they’re applicable here as well.

If your game doesn’t have matching audio for captions, I agree, definitely.

However, I tend to pair subtitles/captions with actual audio so I don’t want users to be able to finish reading the text before the matching dialogue audio is finished. I want to mimic the sensation of personally having to listen to someone up close, while keeping accessibility in tact.

I also do add extra reading time depending on the animation speed + average reading time of my target audience, so these things wont be an issue.

2 Likes

Agreed, but that’s not quite what I’m talking about. I don’t mean to say the typewriter effect as a whole is bad (because it isn’t) - rather, your text would be more readable if it didn’t move around on the screen after it’s appeared, even if you’re showing it grapheme by grapheme :stuck_out_tongue:

Consider which of these two examples would be easier to read - on the left, graphemes always appear in their final location, meaning you don’t have to adjust where you’re looking, even if the animation isn’t complete. On the right, all the characters are constantly jumping around, inhibiting reading progress:

(anyway, let’s get back on topic - we can discuss this elsewhere!)

6 Likes