Increase/Remove the 16 Kibibyte .Text limit

[boatbomber (Zack_Ovits)]

The .Text property of TextObjects is limited to 16 Kibibytes (16,384 character length string).

When using RichText tags in our strings, this limit can be hit surprisingly fast, getting our text cut off as well as resulting in unclosed tags causing RichText failure.

For example, if you’re highlighting words in your text you’ll have things like
<font color="#10c221">word</font> which takes your 4 character word and ends up with 33 characters, just to highlight this one word.

Please increase/remove the 16KiB limit so that we can make use of RichText without running into this wall. The limit should be 200,000 bytes not 16,384 bytes as that is the limit for StringValues and other string properties.

---

It’s worth pointing out that if you try to set a string that’s 200000+, you get this error:

String too long - LocalScript

But if you try to set a string that’s 199999, you get no errors and it just silently cuts your text at 16384.

---

Edit: Adding a use case to prove my point about how deceptively low this limit is.

If you want a rainbow text effect, you’d have each character be another color. As proven above, adding a color adds 29 characters so each character you have becomes 30.
16384/30 = 546. If you want rainbow text, you can only have 546 characters.
That’s not even two tweets.

This tweet alone is taking up more than half the budget of the .Text property if I were to apply richtext color to each character. If I were to apply bold as well, we’d be closer to 3/4th of the limit. Just from this one tweet. This text right here. That’s all it takes.
Increase!

[rogeriodec_games]

I discovered this limitation today and realize this request is almost 2 years old.
It is impossible to work with large texts this way.

[fares14213]

I have a idea:
You have just to create a UIGridLayout or UIListLayout and then you add multiple text.

Or create you own layout for the text.

[DukeAunarky (Aunarky)]

I’ve created a map importer plugin that I’ve created for my game’s community. It revolves around the fact that exported data needs to be in chunks of 16k. The more blocks there are to copy the more convoluted it is to continuously copy many blocks. If Roblox were to remove this limitation, I would be able to support more objects without having this sort of limitation and custom maps can have a lot of depth.

[Ax1sAng1e (Pastor James)]

I ran into this issue while trying to do a replay save system where players could possibly save a game replay, put it into studio, and play it back with new camera angles and record it to a video. The character limit is very very tiny and a 20 second “recording” would easily pass the limit 5 times.

[LovreDev]

You’d need to copy text, place it in notepad, then copy the second text, and connect them which is unreliable

[DukeAunarky (Aunarky)]

Could the team consider looking into this? It’s such a small change that would open up so many possibilities for data inputting

[Ethanthegrand14 (Ethanthegrand)]

I keep running into this limitation. Especially when working with rich text and compressed data

[BizzarBlitz]

Although the text limit has yet to be increased, RichText tags no longer count towards the limit, so the original use case has been solved!

[GamEditoPro]

But what’s about TextBox?..

[moo1210]

Can this still be raised? Rich text markup ignoring the limit doesn’t solve the fact I can’t copy and paste data/scripts.

[Tiffblocks]

Today I enabled a change that improves this.

Now, you can set the Text property to the same size as any other string property (~200KB). When hitting this new limit, it will actually throw an error, like other string properties do. The previous behavior was that it would silently truncate, which could produce corrupted strings.

A new text limit has been added which limits the number of glyphs that get rendered. This means that rich text tags do not count towards this limit, and Unicode characters that are more than 1 byte do not count as multiple “characters”. For now, this new limit is set to 16384, which is the same number as the previous limit. Raising it further than this would run into engine limitations.

Here’s a table that lets you compare how much each string contributes to the length limit:

string	old	new
a	1	1
<font color="#10c221">a</font> (if RichText is set to true)	30	1
fi (a common ligature)	2	1 or 2 (depends on font)
好	3	1
ã	2	1
참 (in normal form D)	9	1
🌈	4	1
👩‍👩‍👧‍👧	25	1

Specific details:

• The old limit counted how many bytes the string took up, in UTF-8 encoding.
• Thew new limit counts how many glyphs are used for rendering. Ligatures of 2 or more characters only count as 1 glyph. Some characters might generate more than one glyph.
• The new limit is only applied during rendering, it does not truncate the actual contents of the Text property.

[SomeFedoraGuy (Him)]

Well dang, thank you a lot for this!!

[boatbomber (Zack_Ovits)]

This is fantastic!! You’re the bestest.

Does the rendering limit start counting from the first characters of the string, or the first glyph that is actually rendered? IE: a really long paragraph, but clipped by a scrolling frame or screen border. Would scrolling to the bottom be blank because the clipped characters above were counted?

[Tiffblocks]

Yeah it’s from the first character of the string. It doesn’t take clipping into account currently.

[boatbomber (Zack_Ovits)]

Would it be possible to change that? If the glyph limit is due to an rendering limitation or vertex cap, then non-rendered characters shouldn’t be approaching that ceiling, much like non-rendered tags and ligatures characters.

This update does make the “paste a bunch of encoded data” use case possible, but users are likely to think that their paste action failed if the text area is blank since it stops rendering after the portion that is scrolled above. Other use cases, such as my in-game markdown editor & viewer, are still unable to reap the rewards here.

This is a massive step forward for sure, and I’m hopeful that we can get this last piece of the puzzle to make this issue truly resolved.