Hacker News Reader

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

Cheers, Thomas Oltmann

Hello, thanks for reading my (probably not really kind) feedback!

> 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!

I'm utterly delighted that you have the courage to just put it out there. It doesn't need to be complete at all. For some purposes (for example rendering a font that consists of shapes), the current state of the code may actually be perfect.

Is CJK support any special compared to "Western" font rendering except that the font files are much bigger?

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

> Is CJK support any special compared to "Western" font rendering except that the font files are much bigger?

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

Ah ok, IFIR for Korean we "prebaked" the required combinations offline needed in our displayed text, and (I guess) the most common combinations needed for user names.

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.

"Unicode support" is subtly different from "CJK support". The former is far messier than the latter.

When writing my own font library I found CJK a bit harder but not impossible. Reading all CJK letters and rasterizing them takes like a GB of memory and many seconds.

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.

You can do CJK with degraded quality using only simple cmap processing. There's another layer that requires more sophistication: dealing with Han unification, processing variation selectors correctly, composing Hangul jamo.

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

> UNIX could be simple, because it was targeted for a very small group of people, mostly always using ASCII. 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’.

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

UTF-8 is not Unicode. UTF-8 is a good encoding of a (IMO) bad standard.

This comment ought to suck less. This is baseless criticism of a cool new project someone was brave enough to build and put out there, with a free software license no less.

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.

> It's just baseless criticism of a cool new project someone was brave enough to build and put out there

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?

The problem isn't with criticism, it's with baseless criticism.

I wouldn't call my criticism to the 'suckless' philosophy baseless. I think my comments below provides some reasons why I'm criticizing. This[0] might be called baseless criticism though.

> 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

It was baseless. You had no evidence CJK will not be supported. It was just a baseless condemnation of the project because the readme referenced suckless.

I'm keep saying this (and it's mentioned in the original comment) - it's not criticism to the project, it's criticism to the 'suckless' philosophy. I have total respect to the project, and I believe that if this project can succeed in having comparable features with less complexity with FreeType, it will be great.

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

You have to keep saying it because you haven’t explained why referencing suckless has any bearing on whether the project will support CJK. In particular you have no basis for this statement:

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

> UNIX could be simple, because it was targeted for a very small group of people, mostly always using ASCII.

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 don’t understand how being suckless translates to not supporting CJK? The library purports to support UTF-8, which includes CJK characters.

It's based on my personal experience. Very subjective.

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.

I tried to see if this library would work with CJK fonts, but unfortunately the CJK TrueType fonts shipped with macOS are all in .ttc collections which the library doesn't appear to support (sft_loadfile fails), so there's that.