Hacker News Reader

Comment by flohofwoe | Hacker News Reader

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

View on HN

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

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

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.

Reply on news.ycombinator.com