The multi language example for Thai looks like it is rendering wrongly.
Proper rendering: ความสูง
Proper rendering: ความสูง
I did some research a few years ago on defining shaping by composing several simple finite state machines together, and am confident it could be made to work. The problem is, it doesn't work with existing fonts, the rules for shaping would have to be redone. But for fonts shipping in an embedded device, this would be entirely practical, and would be a lot faster and a lot less code than a solution based on HarfBuzz.
I'd need some incentive to complete this research. If someone wants to pay for it, please get in touch.
However, this framework looks promising so for instances where multiscript is not needed I’ll be interested in seeing how this one checks out.
I've worked on text rendering in the past, and the amount of subtleties in how each language is rendered and the exceptions/code paths that must be implemented to properly support said languages is not insignificant. Mind you, I say this as a native speaker of these languages. I don't want to imagine the amount of effort and work that would be required to support a language I don't speak. Doubly so if I'm not being payed for it.
If you need support for a language you speak, help the developer by implementing and contributing the support yourself.
PS: This isn't aimed at you specifically, but to those who criticize projects for lack of language support without understanding the effort required.
We don't disagree here. This is the reason why rendering support for non-Latin scripts is usually abysmal on most software like op. It's why authors need help and usually won't do it themself.
> Thus, it's a major architectural decision to support complex scripts at all, and to figure out how to do it.
That's all the more reason to contribute to the project.
> It's not useful advice.
Perhaps it isn't very practical, but someone has to do it. It's also better than the alternative of just complaining without contributing towards a useful result.