Ok, rich text is always a good litmus test for a gui library. I get from this that ImGui is unfortunately not based on a good, versatile graphics engine.
Dear ImGui doesn't have a "graphics engine", the actual rendering is done by user-provided code which maps vertex- and index-arrays, and draw commands to system 3D APIs like D3D, Vulkan, Metal, GL etc...
Font handling is based on stb_truetype.h, but can be replaced with FreeType:
In any case, versatile text rendering is certainly not the design focus of Dear ImGui (AFAIK there's also no support for RTL layout), instead it is mainly targeted at quickly creating specialized UI tools (especially inhouse tooling for game development), less at creating end-user applications.
There's plenty of UI frameworks to create "end-user applications", but hardly any that fill the specific niche served by Dear ImGui.
There is microui if you want another one. Much more barebones as the name implies, but very easy to extend! Pleasant even if a bit quirky. Also nuklear, but haven't really gone much in depth with it.
Could you expand a bit on 'immediate mode design purity'? I've done immediate mode stuff from scratch and my experience had been "just write whatever code you need to get it to work," there hasn't really been an overall architecture guiding it. Never worked with an im library before.
Looking at the Nuklear example code again it turns out that I was remembering wrong. I seemed to remember that Nuklear requires to store persistent state on the API user side and pass that into the Nuklear functions, but this was actually microui 1.x (which also has been fixed in the meantime in microui 2.x).
Sorry about the confusion.
E.g. in microui 1.x defining a window worked like this:
The focus for this library is something else entirely which doesn't seem to align with your needs. Nevertheless, you are supposed to make the engine yourself, imgui is made to be bolted on top of that. And does a great a job.
