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