However, this framework looks promising so for instances where multiscript is not needed I’ll be interested in seeing how this one checks out.
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.