> 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).

Cheers, Thomas Oltmann

> All I can tell you is that right now, CJK, Cyrillic etc. are still on my radar.

That's great to hear! As I've mentioned in another comment, I'm not opposed to simple software - simpler is better, but not at the sake of features. I would truly be very grateful if you can implement the level of support in simpler code.

> Actually, suckless projects are getting a lot better about this recently.

That's great to hear. I hope projects become simpler and more correct.

Thanks for caring, and writing this library!

In my experience, it gets interesting with languages like Arabic which need special case handling for characters at the start and end of words, but those conversions can be applied before handing the UTF-8 string down to rendering. Oh, and the right-to-left rendering.

We have support for CJK and Arabic script in our game's text rendering, CJK was straightforward (only the massive rasterized font bitmaps are a problem), while Arabic was a lot more effort.

Other simple text rendering solutions also don't seem to have much of a problem with CJK (e.g. stb_truetype + fontstash):

https://floooh.github.io/sokol-html5/fontstash-sapp.html

I'm mostly thinking about the composing. For example, the character '한' is composed with 'ㅎ', 'ㅏ', 'ㄴ'.

There are multiple unicode representations for each character, which means there's a one code point '한' representation and it's also allowed to have a 'ㅎ+ㅏ+ㄴ' representation. If the program is just naively searching through the code points the font is supporting, 'ㅎ+ㅏ+ㄴ' won't be rendered properly. (In the real world, most non-Korean companies that implement custom text rendering, even big ones like Adobe get this wrong.)

This only works if the text is (mostly) known upfront of course.

As far as I know this isn't needed for the Chinese and Japanese writing systems we are using though, only for Korean.

If people want their software to work well across the world, they should not use simple libraries like this. Unfortunately, software that gets it right is complex and messy. See "Text Rendering Hates You" for a taste of some of the issues, or some of my blogging about skribo (I tried to solve some of this for Rust but ran out of time on my contract).

So what I do is don't parse the font file fully, but store the location where litters live memory and only parse and render them when they are needed. Most CJK letters are never needed.

I don't have good support Arabic and Hebrew, they feel harder.

The main author of UNIX is also the author of UTF-8[1]. The software hosted at suckless.org often isn't very useful and the people associated with the project often aren't very nice, but the comment about the people behind UNIX here is unfounded.

[1]: https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt

Nothing about an ethos for simple software suggests a lack of CJK support. Nothing on this page suggests a lack of CJK support - in fact, the explicit reference to UTF-8 suggests the opposite.

I'm not trying to criticize the project itself - I think that a 1KLOC C font rendering library is cool. (I'm not sure if it counts, but I also upvoted & starred the repo as well.)

I was criticizing a bit about the 'suckless' philosophy which aims 'simple' software, as I've seen a lot of them recently. (Hence the off topic mention.) I wasn't trying to be harsh or anything - I had good intentions when I was writing the comment. (Maybe my not-good English skills might contribute to the harsh feeling :-()

I personally find that not allowing any criticism just because it's 'free software' and is provided 'as-is' isn't really productive - why would HN exist then? To fill up with praise and applause?

> trying to rewrite complex projects into simpler ones without careful planning of how the new projects will handle complexity makes more inconsistent, divisioned ecosystems.

> Trying to cater to a large group of people will always be complex. And trying to cater to a large group of people is NOT the definition of ‘bloated’.

[0] https://news.ycombinator.com/item?id=14553552

Also, the mention of CJK support is based on my personal experience. (I've mentioned it here[0], previously.) Much bigger open source projects like whole linux distributions or even proprietary software companies don't do CJK (or at least Hangul) properly. I'm pretty sure, from my experience that a small library fails to do it properly. If it does (as I've mentioned above), it would be great.

[0]: https://news.ycombinator.com/item?id=22933613

“Ok, this is a bit of a offtopic rant, but this project seems to be aiming ‘suckless’[0].

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.”

This was the very same group of people that developed UTF-8 and implemented it in the simpler Plan 9 system.

If you want CJK support, I am quite sure patches will be welcomed.

I feel that CJK user experience or other features that the core maintainers don't use isn't taken as importantly as simple code in a lot of open source software, especially the ones that wants to be 'suckless'. I would truly be immensely grateful for this author if this is not the case and every feature of TrueType gets implemented - especially if with more simple & lightweight code.