I’d really like to use JUCE for a big project that currently supports many languages and character sets. In the current framework, “automatic” font substitution is happening that allows for non-Latin characters, without any kind of special font handling in the application logic.
Even in an English-only application, it would be nice for users to enter text in their native language when, for example, setting a label for an object. In my current framework, a single Unicode string can have a mix of English, Japanese, Hindi, etc. and it all works.
This doesn’t work at all in JUCE, does it? I can’t seem to enter non-Latin text into a TextEditor, or show it in a Label. Is this something we can expect to come in a future update?
I want to recommend JUCE for our product, but it’s hard when I have to tell the team we can no longer have a Japanese or Chinese version of the software.
(Not to mention input methods, I suppose. If TextEditor is not a wrapper around the native OS control, then I guess it won’t support Japanese input anyway, right?)
This has become a pretty common issue people have with JUCE. I’ve heard that fixing this is one of the big things planned for JUCE 8, which is still a while away.
This thread is a collection of all the times it has been discussed previously, and it also offers a few solutions:
If you draw fonts with AttributedString on macOS or Windows, it should allow font fallback.
If you want a solution that will also work on Linux, and that will also work with default JUCE components without modifications, you might want to check out the solution I propose in my last post here. If you create a font that contains all unicode characters in it, you can reliably draw non-latin text anywhere you want, at the cost of more memory usage and slightly worse startup time.
Thanks. In one of those threads I think I saw you say “I’d recommend against using my code, I’ve stopped using it myself too”. I am certainly wary of trying to modify every single control that displays text. Relying on tried and tested controls is one reason I’m looking at JUCE. I guess the gigantic font solution might work - I’ll take a look at how feasible that is. I suppose there’s a way, maybe through the theming system, to tell JUCE to use such-and-such font for all its controls.
I expect JUCE would still not really handle things like Japanese character input that the OS normally handles.
Yeah, my earlier attempt at writing code to solve this didn’t work very well, the later solution (using a complete unicode font) does work well for me.
I’m not sure about character input, copy-pasting Japanse text does work.
Hey, thanks for linking to my thread. I was hoping it would become useful eventually.
I’m currently working on a markup display Component which I’m going to share on GitHub (hopefully later today).
It’s based on the AttributedString class and I was surprised that with the right font (in this case, Helvetica Neue on MacOS) it displays non-Latin text correctly out of the box.
That looks like a really handy component. I can see uses I would have for it. I’ve just got to figure out the rest of my international strategy, and whether JUCE can be a part of it. There seems to be a font workaround to display non-Latin text, but for users to type in their native language, I have to tell them to type in a text editor and copy and paste into my app. I’m not sure that will fly.
It would great if the JUCE devs said we’re definitely fixing non-Latin display and input.
I was afraid that that might be the case. I think if (or rather, when) I will encounter this problem, I’ll merge some of the Google Noto fonts for the languages I need. As I understand it, this is possible (for example with pyftmerge) for up to 65535 different glyphs (see How to combine two or more fonts? · Issue #167 · notofonts/noto-fonts · GitHub).
