[BUG] The result of Graphics::drawText is sometimes incorrect

Development
1

When displaying “1.19.0 [1]” using drawText(“1.19.0 [1]”, …) in JUCE 8, it appears as “1.19.0] 1]” like this:

example

My environments are Windows 11 and MacOS Sonoma 14.1.1, and both experience a similar issue. The JUCE version is 8 (commit hash 61a03097ec9e01693c87ac71935e97b9714cff1a at the 8.0.0 tag).

This issue can be reproduced with the following steps:

  1. Open examples\DemoRunner\Builds\VisualStudio2022\DemoRunner.sln, build, and run it.
  2. From “Browse Demos,” select “GUI,” then “CodeEditorDemo.h,” and input “1.19.0 [1]” in the code editor.
  3. It will be rendered as “1.19.0] 1]”.

I have determined that Graphics::ConfiguredArrangement::arrangement already contains glyphs in the incorrect order when rendered, but I could not identify the root cause.

Is anyone else experiencing a similar issue?

2

+1

MacOS 14.5 Sonoma , JUCE 8

Also : 1.19.0 (1) → 1.19.0 )1)

3

I think I’ve identified the cause of the problem. In the implementation of the Unicode Bidi Algorithm, when classifying characters within brackets, according to UAX #9: Unicode Bidirectional Algorithm

Note that EN and AN should be treated as a strong R type when searching within the brackets.

It seems that the implementation of this part in JUCE is incomplete.

Here is the patch to fix it: Unicode: Categorize numerics as strong R type when searching within b… · kbinani/JUCE@6b10240 · GitHub

I hope this report can be helpful to someone.

3 Likes
4

Hi, thanks for the suggested fix.

This seems to fix the drawing issue at first glance but still some inconsistencies “1/8 (3)” if we delete the last “)” the other one will invert.
This will also happen when writing “1/8 (3” will output “1/8) 3”.

May I ask if you can also reproduce this one?

Ended up just forcing TextDirection::ltr on getEmbeddingDirection and resolveNeutralTypes

1 Like
5

Thanks for submitting this. I originally had a case for dealing with numbers but it would fail certain specification tests. It looks like I was doing it in the wrong place.

1 Like
6

This will also happen when writing “1/8 (3” will output “1/8) 3”.

This can be reproduced even after applying the patch, and it seems my patch is still incomplete.
Thank you for pointing that out!

7

Thank you for your reply.
I have two apps on the Microsoft Store that use JUCE. Before JUCE 8, I had to bundle large font files with my apps to render non-Latin text, but that’s no longer necessary.
Although there are some minor issues like this one, overall, I’m very satisfied with JUCE 8 :kissing_heart:
I hope this issue will be fixed in future releases.

1 Like
8

A fix has been released on develop

2 Likes