Unicode text rendering & editing in 2022

@otristan We’re already doing that, and we’re using a font that is capable of rendering Unicode characters, including Chinese characters and emojis.

It works up to a point, but:

  1. I had to manually extend juce::Label to support it. That shouldn’t be necessary.
  2. juce::TextEditor doesn’t support TextLayout rendering and can’t render Unicode as a result.
  3. It doesn’t work if you use OpenGL rendering on Mac
  4. To date, I’ve had to investigate, implement workarounds for, and report, several Unicode text rendering issues. Very time consuming.

TLDR; JUCE doesn’t support Unicode text rendering properly in 2022.

1 Like

As Ben says the Unicode limitations are much more than rendering emojis. Its blocking us from writing a professional multilingual application because there is no mechanism to edit unicode text properly.

Surely a modern commercial cross platform framework like JUCE needs to have proper support for languages other than English. This is not strictly a feature request but a deficiency in the framework itself.

Editing Chinese text and emojis in a juce::TextEditor

…vs the equivalent in a native Windows text editor:


I agree this should be supported out of the box.

@otristan yes the 99% reason we use JUCE is for cross platform UI development.
Its lacking fundamental functionality if it cannot render and edit unicode text properly. All our applications are multilingual (english, french, chinese, japanese, korean, …), so this presents a major issue for us if text rendering doesn’t work out of the box. Single byte lunicode characters render OK but many double byte ones do not.
I’m honestly surprised that more developers haven’t complained about this.

1 Like

+1 to all of you!
Proper text rendering with font fallback, we have been asking for this for more then 10 years.
JUCE 6.1 was all about accessibility features, this should definitely have been part of this.


+1, automatic font fallback is so basic and should be supported.

Use a font that supports all languages are not realistic.

I’m also getting complaints from users because they can’t write or label things in our GUI using eg. Chinese characters. We don’t need emojis etc, but we do need users to be able to enter, lets say, track names in their native language. Is this just a font issue on my end or a deeper issue?

you need to change the implementation of paint to use TextLayout instead of drawText

Thanks. I will try that. I also see that there is something on the horizon for this with Juce 7. So I might just hang tight until I see what happens there

Cannot use this work around for texteditor though

I also ran into this issue, so I created a JUCE module for it:

It’s based on the regular TextEditor from JUCE (therefore, GPLv3 licensed, though anyone with a JUCE license has my permission to use this in any way they please). All it really does it replace the regular text drawing with AttributedString. It’s very simple, and my test results so far indicate that it behaves the same as JUCE’s TextEditor.

Like Tom said: it might not work with OpenGL (still have to verify that) and I also experience some problems with emojis. I might fix that, but the most important thing by far is that it allows non-latin text.

I’m also open for PRs if anyone has any further improvements they want to share.


What do you mean by ‘allows non-latin text’, that was always the case right? If of course you use a Font that contains the necessary glyphs that is.
Or does your editor have a font fallback mechanism, because that would be really nice.

And what also would be a very nice addition to be able to get the attributed string properties at the caret selection, so you can actually create a proper text editor which the user can use to to change the attributed string properties at runtime. Add some serialisation an we finally have a much needed Text Editor. Because right now the term Editor is not applicable if you ask me.

(As requested here )(Rich Text Editor)

Yeah exactly, it does font fallback. Many font don’t support non-latin characters, including the default one that JUCE uses.

Rich text editing sounds like a good idea, it’s probably doable too. I also want to make it jump to the end of selection when using left and right arrow keys, which the current editor doesn’t do.

1 Like

We’re currently implementing full Unicode support with proper font fallback. It is taking a little while, as you can imagine.

Only macOS can sort of render non-ASCII characters correctly (because all the glyph handling is done within CoreGraphics); it’s not configured for Unicode in its current state.

Windows and Linux have no code paths for multi-layered glyphs. TextEditor doesn’t handle clusters at all.

All of this is being rewritten to handle it all.


Good to know, I’m looking forward to that!

I glad that this is just a temporary workaround, and that there’s a real solution in the making :eyes:

Glyph generation and font rendering really is a topic that looks easy from the outside and gets unbelievably huge once you dive into the rabbit hole. Did it for the past months myself in another context. Great to hear you’re working on this!

While I want to give you all the time you need, an approximate release date/year/century would be great - that would help me decide integrating @timothyschoen s solution or keep my feet still and wait :slight_smile:

@tschnz I’d recommend against using my code, I’ve stopped using it myself too, so it’s not used in production anywhere right now. The problem was that using an AttributedString doesn’t work on Linux and Windows, only macOS. I believe on Windows it only worked when I was using an OS font instead of a custom font?

The solution that I landed on in the end, is to just ship a huge font with all languages in it, like Go Noto Universal. The drawback is that it consumes some memory and slows down startup, but it does allow my users to write text in any language.

For my own project, I’ve merged it with the Latin characters from Inter and added emoji to it as well, you can find that one here.


Turns out we can’t even use the (arguably more ‘modern’) circle character (●) for password entry! Back to the good old asterisk I suppose.