Page MenuHome

Emoji Unicode codepoint support
Open, Needs Information from UserPublic

Description

Hi,

in a text object I tried to insert some unicode codepoints from the Emoji section (e.g. this one: https://emojipedia.org/grinning-face/, codepoint=😀 U+1F600). I used the font Segoe UI Symbol (I'm on windows 10) for the text object. The grinning face is for sure in that font, but in blender there is always a rectangle displayed!
I tired the copy and paste method and a scripting method with bpy.data.objects["demo"].data.body = "\U0001F600" (my textobject ist named "demo", but bothe results to the same rectangle.

My guessing is that Blender is not able to process unicode codepoints above hex FFFF, but this is only guessing

Bernd

Details

Type
Bug

Event Timeline

I used the font Segoe UI Symbol (I'm on windows 10) for the text object. The grinning face is for sure in that font

Actually you can't assume that, just because you can enter that color emoji character while having that font selected in other applications. That font is a monochrome Truetype font (black-strokes and a maximum of 65,536 glyphs). So when you see a color emoji that is because the operating system is doing a fallback from that font to another that supports color emojis. So "Segoe UI" does not include that character and we can't really do the same fallback trick of substituting a different font because our font drawing library does not (yet) support color fonts well.

But there are regular (monochrome) characters in the regular unicode range that include smiling faces. Notably U+263A, which is 'WHITE SMILING FACE', but the Segoe UI does not include that symbol. But other fonts do. Following is in in Arial, which includes that glyph:

Hi harley,

sorry for misleading you! You are right, this is a color emoji. But if you copy that codepoint and paste it in wordpad on windows it will be shown in monochrome

and the choosen font is shown also. According to https://www.fileformat.info/info/unicode/char/1f600/fontsupport.htm
the grinning face in in the Segoe UI Symbol and in the Segoe UI Symbol fonts (both available on windows 10)

The symbol from your picture is a smiley not a grinning face!

There are also a lot more emojies available. They have all in common that there codepoint is above hex FFFF, so they do not fin in 16 bit. In python you have to use the upper U escape sequence instead of the lower u. For example print("\U0001F600"). You can excecute that on the commandline if you have the correct font installed. I tried this python3 in putty on my little raspberry server. It's not working an the windows commandline.

Hmmm... Sorry, but I was looking inside the "Segoe UI" font not "Segoe UI Symbol". Not sure how I missed that part of your post.

I'm quite certain that our font library (FreeType) properly supports glyps above FFFFF just fine, so would suspect that there is indeed something in our code keeping those characters from displaying. Although I doubt anyone would take up support for emojis within blender as an urgent issue, I'd guess this will get fixed before too long for other reasons. There are some plans to support font-shaping (using Harfbuzz for example) to support some complex languages better and quite often many of the combined characters are above FFFFF.

I personally would not consider the current behavior as a bug though as we currently support the vast majority of glyphs for most languages. Anything more would be nice, but that's more of a feature request.

That's pretty fine for me. Can you change this or do I have do do this?

Sybren A. Stüvel (sybren) triaged this task as Needs Information from User priority.

Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

A guideline for making a good bug report can be found here: https://wiki.blender.org/wiki/Process/Bug_Reports

Marking as "Incomplete" until the requested information/data is provided.

Here is a blend file demonstrating the bug

Here is the system-info.txt file

Bastien Montagne (mont29) raised the priority of this task from Needs Information from User to Waiting for Developer to Reproduce.Tue, Aug 20, 11:24 AM
Jacques Lucke (JacquesLucke) lowered the priority of this task from Waiting for Developer to Reproduce to Needs Information from User.

Seems to work just fine for me:

Note, I had to select a different font file, but it should be the same font.
So maybe you use some incomplete font file?