6 ms·

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

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. 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’. 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. Quoting the suckless philosophy[0]: > Code complexity is the mother of bloated, hard to use, and totally inconsistent software. > Ingenious ideas are simple. Ingenious software is simple. Simplicity is the heart of the Unix philosophy. 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’. [0]: https://www.suckless.org/philosophy/ https://www.suckless.org/philosophy/

flohofwoe 7y ago
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 https://floooh.github.io/sokol-html5/fontstash-sapp.html
- pcr910303 7y ago
  > 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.)
  - flohofwoe 7y ago
    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.
  - userbinator 7y ago
    "Unicode support" is subtly different from "CJK support". The former is far messier than the latter.
- treeform 7y ago
  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.
- raphlinus 7y ago
  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).
Aeolun 7y ago
I don’t understand how being suckless translates to not supporting CJK? The library purports to support UTF-8, which includes CJK characters.
- pcr910303 7y ago
  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.
oefrha 7y ago
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.
yiyus 7y ago
> 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.
tomolt 7y ago
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
- pcr910303 7y ago
  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!
- cerberusss 7y ago
abjKT26nO8 7y ago
> 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 https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt
- AnIdiotOnTheNet 7y ago
  UTF-8 is not Unicode. UTF-8 is a good encoding of a (IMO) bad standard.
ddevault 7y ago
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.
- pcr910303 7y ago
  > 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?
  - ddevault 7y ago
    The problem isn't with criticism, it's with baseless criticism.
    - pcr910303 7y ago
      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 https://news.ycombinator.com/item?id=14553552

flohofwoe 7y ago

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 https://floooh.github.io/sokol-html5/fontstash-sapp.html

pcr910303 7y ago
> 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.)
- flohofwoe 7y ago
  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.
- userbinator 7y ago
  "Unicode support" is subtly different from "CJK support". The former is far messier than the latter.
treeform 7y ago
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.
raphlinus 7y ago
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).

Aeolun 7y ago

I don’t understand how being suckless translates to not supporting CJK? The library purports to support UTF-8, which includes CJK characters.

pcr910303 7y ago
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.

oefrha 7y ago

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.

yiyus 7y ago

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

tomolt 7y ago

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

pcr910303 7y ago
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!
cerberusss 7y ago

abjKT26nO8 7y ago

> 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 https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt

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

ddevault 7y ago

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.

pcr910303 7y ago
> 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?
- ddevault 7y ago
  The problem isn't with criticism, it's with baseless criticism.
  - pcr910303 7y ago
    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 https://news.ycombinator.com/item?id=14553552