utf8.new(imageId: string, rectSize: Vector2?, rectOffset: Vector2?): string

within the current development sandbox, there exists no functionality to create unicode symbols or images to be embedded in strings of text.

it would make the most logical sense to turn to the utf8 library, which deals with unicode characters and even has its own private-use-area for application (Roblox) -specific characters.

unfortunately, the current utf8 library and other text-related roblox services (textservice, etc) do not have any functionality to create developer-defined characters.


Case 1: Counters and visual quantifiers

in its most simple form, “embedding” an image into text consists of appending an ImageLabel to a TextLabel, similar to this image below:
image

Case 2: Dynamically-set interfaces

(Gamepad accessibility, input displays, killfeeds)

for dynamically-set ui (or anything remotely complex), such as displaying platform-specific controls or kill-feeds in combat games, this becomes much more of a chore as unnecessary operations and instancing need to be performed to achieve something that would ideally be as simple as setting the .Text of a single TextLabel to:

"\u{E000}: Action" for action/keybind displays
"Player0 \u{E000} Player1" for kill-feeds
"\u{E000}" 99,999 for counters

wow! a lot easier than doing something akin to:

TextLabel.Text = "Action"
ImageLabel.Image = "rbxassetid://"
ImageLabel.Position = UDim2.fromOffset(TextLabel.TextBounds.X, 0)
...

Case 3: Language barriers

developer-defined unicode symbols would also open up a lot of avenues for player-to-player communication, where a unified, easily-recognizable symbol/icon/emoji would replace normal text, such as situations where players with different language backgrounds are trying to communicate:


Proof of concept

case #3, which stemmed from a reply from the linked release note, and is the acutal basis of this entire feature request, is the most feasible case to make a proof-of-concept for as provided below:

…it uses TextChatService’s OnIncomingMessage callback function to :gsub() the message text with a conversion table that most closely shows what developer-defined utf8 symbols can be used for in regard to cross-language communication:


Feature request

i propose a single function to be added to the utf8 library, which would cover all bases of this feature request:

utf8.new(imageId: string, rectSize: Vector2?, rectOffset: Vector2?): string

…which indexes imageId in the unicode pua range, then returns string Codepoint (something like "\u{E000}") to be stored/cached for developer usage in runtime

rectSize and rectOffset are for when imageId is passed as a spritesheet, for example:
example-05
…this behaves like ImageLabel.ImageRectSize/ImageRectOffset to reduce rbxasset:// bloat brought on by uploading/loading assets one-by-one

--src/Library/EmojiConsortium.luau
local imageId = "rbxasset://ilovecats.png" -- 2x2, 128x128 sprite sheet
local imageRes = Vector2.new(64, 64) -- resolution per-sprite

return {
	cats_i = utf8.new(imageId, imageRes, Vector2.new(0, 0));
	cats_love = utf8.new(imageId, imageRes, Vector2.new(1, 0));
	cats_cats = utf8.new(imageId, imageRes, Vector2.new(0, 1));
	cats_face = utf8.new(imageId, imageRes, Vector2.new(1, 1));
}

this is a revised, more concise & simple version of a previous post

19 Likes

Inline images via rich text seems to be a much better solution, as it would allow for everything proposed here and more. The method proposed here seems like it will constrain the images to always be the size of the text, but that is often not what developers would want.

It also seems like it would be a pain to use. Due to this globally defining a codepoint, you must guarantee that the codepoints are always defined in the same order every time each client loads, otherwise codepoints suddenly start meaning different things for different clients.

1 Like

Wait until you discover this cool feature called RichText

This is exactly why in my proposition I have them referenced in a key-value table so that their “alias” points to the same image, although the codepoints may differ client-to-client

If the codepoints differ from client to client, then using them in chat becomes pointless since the symbol one client types may become another symbol for someone else. You could always use a system like on Discord where emojis are represented by a custom format, but at that point you lose the simplicity that having a dedicated codepoint would bring.

Inline images should undoubtedly be possible, I just don’t see a benefit of being able to register private use codepoints over using something else like rich text for them.

1 Like

open your eyes and read and realize that your point is going nowhere

it takes 1 string.gsub call to substitute a developer-defined emoji format in a TextChatService fork to implement custom codepoints in code

1 Like

Fixed link

1 Like

It’s easy to implement sure, but @funwolf7 is concerned about the implementation itself. If you do just have one table per client, then one person could send a message thinking it would show as a robux symbol, and the receiver would see something else, for example. The proposal mentioned by @funwolf7 explicitly references an image URL that prevents this kind of ambiguity.

the alias (table key) points to the same image, regardless of the codepoint stored on the client

image

the offset of the codepoint does not matter because the aliases are all that need to be interacted with

it’s an extremely simple concept to grasp and i’m tired of repeating myself

Lets say that Client1 sends a message in chat that includes \u{E003}, representing the symbol for currency 2. The network dutifully sends over the UTF-8 character to Client2. However, when they render it, it comes out as the symbol for currency 1, which is probably what Client1 did not intend. This is the problem we’re talking about, and these tables won’t fix that, especially if neither the server nor the clients knows what’s happening on the other side.

I can understand the frustration of not one but two people not understanding you, but repeating yourself in an exasperated tone is not gonna help that.

watch the video i uploaded

when implemented correctly to account for mismatching codepoints, there is no possible issue with how the feature request would behave

every client receives a the message ":robux:", and they themselves independently gsub the message with the substitution table. at no point in time is a utf codepoint ever sent over the chat system

@7yooso yo look at this it looks useful

1 Like