Is we must add a “UITK Text Settings.asset” file to our project and drag this file onto the “Text Settings” for our “Panel Settings.” Then we are supposed to drag a “Sprite Asset” onto “Default Sprite Asset” and this will then automatically use this sprite asset for emojis.
I am unsure how to create the appropriate format of “Sprite Asset” for emojis in this regard. From various tools and tutorials I was able to make a “TM Pro Emoji Asset”. Advanced Input Field 2 has a tool for this where I just needed to drag on the emoji.json and emoji sheet from: https://github.com/iamcal/emoji-data
However, this is not the right format for the “UITK Text Settings” field. It must be a “Text Sprite Asset.” If I apply appropriate slicing to the emoji image sheet, right click the sheet, go Create > Text > Sprite Asset, it creates an asset I can drag onto the field with the emojis all in there, but it doesn’t assign usable Unicode to each sprite in Character Table.
There is also the option for Window > Text > Sprite Importer but the emoji.json file cannot be used by this tool as it requests a “Texture Packer JSON Array.”
I have searched for hours now over the past few days and I can’t find any explanation for how to create a Text Emoji Asset that will work for this application. Is there some method I am supposed to be using? Is it summarized anywhere?
There are only 18 threads in this entire UI Toolkit forum with the word “emoji” and none explain this.
Also, does this then suggest you can only have one Emoji/Sprite Text asset in UI Elements per panel? ie. Can you assign another sprite asset to a Label programmatically?
A quick reminder that we are currently working to bring UI Toolkit’s text capabilities to feature parity with TextMesh Pro. If you don’t find the documentation you are looking for regarding the Text Assets in UI Toolkit, you could always have a look at how the same functionality work in TextMesh Pro. Except for the Menu Items and some slight differences, the core features should remain the same.
The “Window > Text > Sprite Importer” is specific to importing sprites packed with TexturePacker in JSON (Array) format. This can be useful as there is an option to use the sprite filename as Unicode.
As you mentioned, the other way of creating sprite assets is from a texture (set to Sprite mode Multiple) where the sprites were defined in the Unity Sprite Editor. You should be able to edit each sprite’s Unicode through the Sprite Asset inspector. (See image below)
Here’s some TMP documentation on how to do the above. It’s really old, but for the most part, it’s still relevant. Doc + Video
As for assigning a sprite asset programmatically to a label, it’s currently not supported in UITK, but there are many other ways to access your Sprite Assets. As shown in the image below, in the Panel Text Settings, you can set a default Sprite Asset, Sprite Asset fallbacks, and a path to locate all your Sprite Assets from the tag. Is there a reason why you would need to also be able to assign a SpriteAsset to a Label?
Also, could you be more precise on what you are trying to achieve?
Thanks for your reply Hugo. There are numerous problems with the suggested current Emoji asset generation process that I think could be solved for all of us all at once by the Unity team, and so I hope you are open-minded to considering the possibility of improvements on your end.
The holes created by this process have necessitated 3rd party solutions, and as chat and other functions become more widespread, many of us will need emoji support. An end user will not understand why we don’t have emojis in a basic SMS or chat type function in 2022. Thus it is not optional for us.
Most of us are creating Emoji assets from the files here:
There you can find sprite sheets in various resolutions for Google/Apple/Twitter emojis. There is also included an “emojji.json” and licensing information for each emoji sheet.
There are 60 rows to each sprite sheet and 58.5 columns. This equates to over 3,480 emojis. The notion that we as end users should sit down and manually sort through 3,480 sprites and enter their unicode by hand in the Sprite Asset inspector is not workable. I hope you can agree.
Even ignoring the fact that this would take hours of painstaking and mindnumbing work during which human data entry error would be an issue, doing so is complicated by the fact that the standard Unity sprite asset generator reads the sprite sheet from left to right in rows, while the emoijs in those image sheets are sorted instead in columns from top to bottom, then left to right.
So we have as immediate output from the Unity tool:
Instead of what it should be which is:
This simple row vs. column issue could be solved by having an option for “read sprite in rows” vs. “read sprite sheet in columns” or something of that nature.
The second problem which is allocating unicode to the sprites could also be solved by having an option to drag on a copy of “emoji.json” from the GitHub link I provided and have it automatically read the “unified” field from that GitHub which is the unicode for each sprite. The code for “emoji.json” is explained simply at that GitHub link.
Built a tool included in that asset a script “EmojiAssetGenerator.cs” specifically to do this which looks simply like this:
In that screen cap, I have dragged on the “emoji.json” file from the Github link given and one of the Twitter spritesheets. Pressing Generate creates a “TM Pro Emoji Asset” which is how I created the asset screencapped above with the correct order of emojis and their unicode allocations.
Such a basic function is necessary at this point in Unity. Perhaps you can contact that user to ask if you can include their tool in your future releases. It is simple and effective. There is no need to ask every Unity user who wants Emojis to sit down and try to punch in >3,480 unicode codes manually in order to do so.
The only problem is that tool only works for creating a “TM Pro Emoji Asset”, not a “Text Emoji Asset” and thus it is incompatible with the UI Toolkit system. So as I cannot enter >3,480 unicode codes by hand, I therefore still have no reasonable method for creating an emoji asset in the UI Toolkit system.
Is this something your team can look at? My only options otherwise are to try to dig through the code of the tool for creating the “TM Pro Emoji Asset” and try to figure out how to modify it to output a “Text Emoji Asset” and/or try to pay that developer to modify it for me.
Doing it myself could burn days or weeks of trying to figure it out depending on how tough it is given I don’t know the inner workings of these systems.
This is something anyone who is creating a chat or SMS type function will need so to me it makes far more sense for Unity to find a universal solution we can all use. Otherwise all of us will have to keep doing the same thing to try to find individual custom solutions for a universal problem.
The third and final problem with the current Emoji generation process for UI Toolkit is it is currently misaligning the emojis. For example, using the string code ‘label.text = “Test” + char.ConvertFromUtf32(0x1F642);’ where I have manually assigned the hashtag emoji from the sprite sheet I generated above to that given unicode produces:
You can see it is aligning the emoji incorrectly and overlapping the text. This is because it assigns the pivot point for the emoji to be its midpoint (for 32x32 emoji, BX = -16, BY = 16). We need this to be the bottom left corner (for 32x32 emoji, BX = 0, BY = 32). Again, it is not possible for me to go through >3,480 emojis and correct these all manually. The Advanced Input Field 2 tool creates the TM Pro Emoji Asset with the correct offsets so no correction is needed. A similar solution is needed here.
This third issue is the least of the three problems though as one can open the asset file and do a simple find and replace for m_HorizontalBearingX: -16 & m_HorizontalBearingY: 16 to solve it. However, again this should be done as part of the automatic built in emoji generation tool.
So those are the main 3 problems making the current UI Toolkit emoji/sprite system unusable:
Sprite sheets are read in wrong direction (rows vs. columns) for emoji data.
No reasonable way to apply > 3,480 unicode assignments to the >3,480 sprites that are made.
Emoji sprites are misaligned in text labels when implemented.
All three issues could be solved by adapting the Advanced Input Field 2 tool l linked or creating your own version of such a device. #1 and #2 are insurmountable currently without a custom or third party solution.
On a different subject, I asked about assigning different sprite sheets for different labels to manage the condition where you have one sprite sheet for emojis, but also want custom UI “emojis” (icons or graphics interspersed in interface design text) for your UI.
I think from your comment, the solution to that would be to make a second “UI sprite sheet” as the fallback sheet and then just assign it unicode values that would not be found in the standard emoji sheet. Thus, normal emojis will be found in the standard emoji sheet and custom “UI emojis” would be found by their specialized unicode in the fallback sheet. I think that makes sense and is easy enough if that is correct.
Any thoughts on the solution to the emoji sheet generation problem would be appreciated. I hope I’ve at least made sense as to what the problem is and what a hypothetical solution might look like.
I decided to move our discussion to a new thread in order to centralize all discussions around the topic of Emojis.
The long-term plan is to add native emoji support to TextCore. This is something we are actively working on at the moment and the plan is to complete it by 2022.2. Native emoji support will allow TextCore users to use the system font that contains all emojis for that specific platform.
As for emojiData (GitHub - iamcal/emoji-data: Easy to parse data and spritesheets for emoji) it’s unfortunately not a format we currently support. However, there might be a way to make the resulting “TM Pro Emoji Asset” generated by Advanced Input Field 2 supported by TextCore. The “com.unity.textmeshpro.4.0.0-pre.1” is a version of TMP where all TextAssets (FontAssets, SpriteAssets, TextStyleSheets…) are shared with TextCore. My hypothesis is that by simply adding this version of the TMP package you’ll be able to use the resulting asset as the default sprite asset in the PanelTextSettings. Note that this version of TMP is a preview version and is only supported in 2022.1 and later. You should also note that ligature (emojis sequence) is not yet supported in TextCore.
Hey Hugo, it’s been 5 months, and I’m just wondering if native emoji support is still on the roadmap for Unity 2022.2 and when that might be coming.
I appreciate your suggestion for the workaround, but figuring from what you said native emoji support was imminent I thought I was better off putting my attention into other development challenges and waiting instead.
Even if a sprite sheet solution works, it will always be less ideal than using the native emoji support, as we won’t have to build in custom 16 MB sprite sheets, deal with glitches from combination emojis (for example some flags or skin tone emojis I think), or update the sheets/code any time the emoji standards change.
No rush, but I’m just curious to know if this is still on the agenda and when it might be expected so I can plan accordingly.
Also for clarity, would the native emoji solution you’re building work with UIElements.Label, TextGenerator, & TextGenerationSettings? Those are the main font based classes I am using that need emojis and would need something that works with all as I use them all in an integrated fashion.
If it works in the old TextMeshPro or UI.Text that would be nice too but less important for me.
There’s been a few setbacks but it’s still in the work. We are at a point where we are adding the last touch, but I can’t communicate any clear timeline of when this will land and in which version. However, it will be backported once it lands.
hello,
emoji support was asked many times…
startet a thread 5 years ago…
but as we see no real progress …
little disappointed about it… we need emoji in mobile all time…
so the sprite sheet creation is the only working solution…
before TMP was acquired by Unity i’ll was in closed contact with the dev…
he had planned the feature back in 2018…
as we see today end 2022 … still NO emoji native support … nor on mobile nor on desktop…
and like you showed … Unity3d messes up the sprite sheet and change the order etc…
it’s not really usable … you have to look and search each time wich corresponding ID in Unity3d it has…
very very annoying …
for mobile stuff i’ll have to use other tools that does the job natively …
M.
We are close to the finish line for basic native Emojis support. We are doing a last round of testing and writing documentation, but the core of the functionality is done and should be available in the next TMP release.
Basic Native Emoji support will also be available to UITK users in a subsequent release.
This is great news @HugoBD-Unity ! Is there some draft documentation to start reading? How is going to be “natively” supported? Like right out of the box, or it will feature on a add-on package?
I’m curious if the TMP Text will render the emoji in the Text UI.
Unfortunately, nothing to share as of yet, but we should be able to release a new version of the TextMeshPro package in a couple of weeks that will support Color Emojis.
By Native Emojis, we mean we’ll support creating FontAsset from OS Emojis Font such as Apple Color Emojis. This will enable users to easily support the native Emojis of a specific platform.
I hope it helps and stay tuned for the next package release!
Hello @HugoBD-Unity how is it going with the release of the new TMP version and which one will be?
And when will it also be available for UI Toolkit?
I can’t wait to see the progress you’ve made on emojis support
Hi @m0s_ivan ! We’ve finally released the new version of the TMP package (3.2.0-pre.4). You can learn more about this new release in this thread .
As for bringing Color Emojis and OpenType feature to UITK, this is our next priority. I can’t commit to a specific date, but 45-60 days seems like a reasonable guess.
I’ve been following on the thread for about a month now
First of all, Hugo - you are a king - thank you for keeping us in the loop
Our UI team wants to add Emoji support to our app, and I was wondering if TMP package (3.2.0-pre.4) is safe for deployment, or should we wait for further updates regarding the Color Emojis and OpenType feature to UITK?
Honestly, I didn’t quite understand the difference
We are about to release TMP 3.2.0-pre.4 as a verified version for 2023.2. However, packages can’t be verified on older versions, but we use the same package across the different versions.
There are still a few issues / limitations related to the new Color Emojis, but the rest should be stable.
Sorry if it wasn’t clear. We can’t verify TMP 3.2.0-pre.4 on older versions of Unity (we can’t verify this package on 2022.2), but technically we are using the same version of the package across the different versions. Meaning we use the same TMP 3.2.0-pre.4 package in 2023.2 and in 2022.2.
You can assume the package is stable and will mostly receive bug fixes even if it’s not verified in previous versions.