Unicode text rendering & editing in 2022

General JUCE discussion
#1

Hi all,

I’m wondering what the situation is regarding rendering and editing Unicode text with JUCE in 2022.

Obviously, there are lots of historical threads about this, with most official responses simply stating that it’s incomplete and/or not possible yet, but a lot has changed recently - not least the PACE acquisition of JUCE a few months back.

For example, with JUCE 6.1.5 I can render Unicode text using juce::AttributedText. There are some issues (see Unicode Rendering Bug (Mac & Windows), for example), but it basically works OK.

And with a few JUCE tweaks, I can even make juce::Label render Unicode text by adding an opt-in mechanism to make it use juce::AttributedText behind the scenes. It’s working pretty well here, but obviously I shouldn’t really have to do that.

But what I definitely can’t do yet (at least not without a lot of work) is let users edit Unicode text with a juce::TextEditor component. I suspect it was written before juce::AttributedText came along and/or that juce::AttributedText isn’t considered fast/efficient enough internally for general text rendering duties.

I’d really appreciate an official update on this matter please. Can we expect a proper, across-the-board Unicode implementation any time soon, or is it still up to us to roll it ourselves using the limited support JUCE provides?

Many thanks,
Ben

4 Likes
#2

Bumping this. Hoping for an official response. Many thanks.

#3

We don’t have an official response with any substance. It’s one of the things we would like to add, but the feature request is not something we are currently working on.

It’s not as simple as just using juce::AttributedText in more places - the OpenGL renderer can only draw paths, so we would need to bundle an entire emoji implementation to add support there.

#4

Appreciate the reply, Tom. And not surprised to hear there’s more to it than meets the eye.

#5

@t0m It occurs to me that it’s not just an emoji thing.

It might not be so bad if it were just emojis, but it’s also Chinese characters, and presumably many other non-Latin character sets too (Japanese, Korean, etc)? Chinese characters don’t render correctly when I paste them into a juce::TextEditor in DemoRunner 6.1.5, for example.

That’s a pretty big problem if you’re writing a multi-language app!

This, and while I’m at it, the lack of modern GPU accelerated rendering options (OpenGL is deprecated), are the two ‘elephants in the room’ with JUCE UI as far as we’re concerned. It’s embarassing when our customers complain about these things in 2022. And our hands are tied - unless we cease development of our app and implement it in JUCE ourselves!

Again, I appreciate your replies and realize you have limited resources. But these are glaring shortcomings that are holding JUCE, and us, back. Don’t get me wrong - we’re big fans of JUCE here, and we want to see it improve/thrive. Please take this as constructive feedback.

2 Likes
#6

You need to implement Label drawing using TextLayout otherwise you need a font that support all the glyph.

#7

@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.

#8

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.

#9

Editing Chinese text and emojis in a juce::TextEditor…
image

…vs the equivalent in a native Windows text editor:
image

#10

I agree this should be supported out of the box.

#11

@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.

#12

+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 Like
#13

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

Use a font that supports all languages are not realistic.

#14

Hi
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?

#15

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

#16

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

#17

Cannot use this work around for texteditor though