Apologies for starting the (N+1)th thread on this topic, but I’d like to understand the state of this issue in 2023, hoping that it would be useful also to other people working with non-latin text.
What I’ve observed so far (working with JUCE versions up to 7.0.7) is the following:
The TextEditor class can display RTL (right-to-left) text (with the correct font), but the words are ordered LTR (left-to-right). Editing text seems sketchy to say the least (e.g. pasting some piece of text will insert it a few characters away from the cursor position).
The Label class can also display RTL text and the word order is correct, but some letters are dropped as described by
@ronaaron in this thread: Graphics drawText etc do not behave properly for RTL text
I’ve seen that people have found some workarounds around some of the issues, like using a font that covers all languages, described by
@timothyschoen in this recent thread: Unicode text rendering & editing in 2022, and implementing custom LookAndFeel text drawing methods based on AttributedString (again by @ronaaron in the thread mentioned above).
Now my question is: is any of this going to change anytime soon (for example with JUCE 7.1), or are these workarounds still the way to go?
Just for the record, here’s a list of all the threads on this topic that I’ve found, in chronological order:
A status update for those who are interested.
I have completed the first stage of work which was creating the AttributedString classes and getting rendering working using the CoreGraphics renderer on Mac OS X. The next step is to start implementing all the Glyph classes I previously mentioned so I can get the software renderer on Mac OS X working.
Now onto some examples. The boxes in the images are all Labels with a border. The Text Engine 1 boxes represent the current Juce Text Rendering Syst…
As I continue my journey into JUCE, I am attempting to get my sample code running.
I noticed that one of my buttons was displaying empty squares, and I fixed that by overriding "getFont()" so the Hebrew text displays.
However, it is drawn left-to-right, and I cannot find any way to tell the TextButton it should render right-to-left. Is there something I'm missing?
I did see the discussions on the text rendering system, but those are all several years old.
How can I best accomplis…
I am wondering whether the default juce TextButton should use TextLayout in order to handle correctly non latin character display.
What do you think ?
We've been trying to figure out why Hebrew text is drawn incorrectly in JUCE (in e.g. buttons , labels etc)
I finally figured out that 'drawText', etc simply don't work correctly.
When I replaced (in my own LookAndFeel) the call to drawText* with AttributedString draw, the text was drawn correctly.
The manifestation of the problem is that chunks of the text will not appear, especially if there is a space (e.g. not-RTL) char inside the string. If the text were "ABC DEF" (assuming they are R…
I added some code in juce_mac_Fonts.mm to handle the reading direction from an AttributedString.
Would it be possible to put this into the code base?
In static CFAttributedStringRef createCFAttributedString (const AttributedString& text) the following was added.
CTWritingDirection ctWritingDirection = kCTWritingDirectionNatural;
case AttributedString::ReadingDirection::natural: break;
we’re trying to use a JUCE TextEditor with Japanese and Chinese glyphs while also using italic and bold text formatting. It turns out the font we’re using (Arial Unicode MS) doesn’t have bold and italic typefaces. Italic is apparently hacked by JUCE’s font drawing using a transform but bold does not work that way.
I tried to find other fonts I could use that support both Chinese/Japanese glyphs and also bold but couldn’t find any. Is there an easy way to use the default system font wh…
I’d really like to know if this is intended behaviour, because if so I can’t use AttributedStrings in various components, because I want to set font.withHorizontalScale() slightly on my main font.
Vanilla JUCE GUI App, Mac OSX Mojave, Juce 6.0.8 (problem exists before this however):
AttributedStringTest.zip (10.3 KB)
void MainComponent::paint (juce::Graphics& g)
g.fillAll (getLookAndFeel().findColour (juce::ResizableWindow::backgroundColourId));
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),…
It was mentioned quite recently that the team is going to reimplement text layout features in JUCE 8. But will that issue be covered?
We’re in the middle of overhauling our text layout functions. It’s a huge task, but at the end of it these issues should be addressed. If all goes to plan it will be part of the initial JUCE 8 launch, but we don’t have a reasonable estimate for a release date yet.
Thanks for the link. I guess for the time being those workarounds are the way to go.