Hi, author here. > For me and a lot of users, that means that this project probably won’t be useful for a lot of non-ASCII users, especially for CJK users like

Hi, author here. > For me and a lot of users, that means that this project probably won’t be useful for a lot of non-ASCII users, especially for CJK users like me. I’m pretty sure CJK support will not get implemented or postponed to the future until one day the maintainer decided the project is too ‘complex’ and not ‘suckless’. I totally understand that suspicion. All I can tell you is that right now, CJK, Cyrillic etc. are still on my radar. In fact, I think libraries' internals already at least partially support them. Only problem is, the API and demo application can't take advantage of that right now, though they will in the future. That being said, it's true that some select writing systems will have lesser support than say FreeType2 provides. That's mainly because TrueType (the font format libschrift is implementing) doesn't support all languages perfectly either. There's no way for libschrift around limitations in TrueType itself, except for perhaps also implementing other font formats like OpenType. (Which I might look into eventually). > Yes, I know that this is an open source project and I don’t need to use this… but it just makes me sad to see essential features for some people will be removed as the name of ‘complexity’. IMHO, this attitude of trying to rewrite complex projects into simpler ones without careful planning of how the new projects will handle complexity makes more inconsistent, divisioned ecosystems. Actually, suckless projects are getting a lot better about this recently. There are lots of internal discussions on how to properly implement minute details of the Unicode standard. Recently Laslo Hunhold even released a prototype library for correct grapheme cluster handling (https://git.suckless.org/libgrapheme/log.html https://git.suckless.org/libgrapheme/log.html). Cheers, Thomas Oltmann