Support for rtl text, and right-to-left languages

[traverseda]

Or google-able documentation of same.

[ocornut]

Hello Alex,
Sorry, RTL isn't supported and I don't plan to support it as it would largely increase cpu cost (which is a highly desirable property to maintain for what imgui is designed for), as well as increasing maintenance cost (things like bi-di text or proper text shaping are not easy to get right). It's not really the expected use case of dear imgui to support all international languages.

[traverseda]

That's too bad, as it limits the inclusion in more serious tools. As an example, solvespace, which is having to choose between

• Their own homegrown immediate-mode gui
• OS specific widget toolkits

and

• ImGui

I'm advocating for ImGui, since portability is one of their big goals and I think OS specific UI toolkits are going to suck. But they're big on accessibility and internationalization, trying to make a good, easy to use, open source CAD.

Done right, this should save them a bunch of time, time that they can focus on making their project good.

So the big questions are

• Are there any hacks what would allow limited support for RTL languages for the time being?

• Would you accept pull requests for optional RTL support? Say, harfBuzz enabled text widgets?

[ocornut]

Are there any hacks what would allow limited support for RTL languages for the time being?

Probably/perhaps, if you are willing to dig into the font/text code, but I expect going from the quickly hacked version to the full internationally compliant version would be rather hard. If you are thinking Arabic for example, it's not just right-to-left (which would be the simple part), but things like bi-directional support and text shaping would be required.

Would you accept pull requests for optional RTL support? Say, harfBuzz enabled text widgets?

Definitively not on Master (because Harfbuzz is a non-trivial complex dependency).
In a branch in theory yes, in practice probably not unless you would be serious about using and maintaining it. It's really not in the DNA of dear imgui to go toward that direction. And I suspect it wouldn't be an easy patch: I don't think harfbuzz was designed for the IMGUI use case and you may need to introduce some extra layer of caching (keyed by e.g. text + render width/pos) because shaping text every frame will be costly.

I realize it's frustrating, but dear imgui is a small library developed mostly on my spare time with limited resources, and even if that sort of feature was easily reachable (which it isn't) I would maybe argue it isn't in the library or my interest to try being a replacement for e.g. QT because I don't have the resources to stretch it to satisfy everyone's needs.

[bluebear94]

Yep, maybe if someone has time to implement that, it could be included in imgui_club.

[ocornut]

Closing this as dropped.

Yep, maybe if someone has time to implement that, it could be included in imgui_club.

It'll most probably have to be a core element.
I think in practice there are a too many things to change and fix to make this doable - and it's quite outside the scope and typical use case of dear imgui to make it worth it. If anyone wants to try hacking something by all mean for go it.

[mwindowshz]

Hello Alex, Sorry, RTL isn't supported and I don't plan to support it as it would largely increase cpu cost (which is a highly desirable property to maintain for what imgui is designed for), as well as increasing maintenance cost (things like bi-di text or proper text shaping are not easy to get right). It's not really the expected use case of dear imgui to support all international languages.

it is possible to use hebrew and RTL with these steps
load font with the glyphs range to support the RTL language letters

then when calling ImGui.Text()
reverse the text and handle utf8 byte size changes

I did not test this on text input

see my example
https://github.com/mwindowshz/imgui_base/blob/main/imgui_add_hebrew.cpp
maybe you can add this to IMGUI source code by creating a set of glyph and using a reverse function

thanks to @harelw
for the support