Hacker News Reader

Comment by rspeer | Hacker News Reader

The unfortunate problem is that any one of these fonts increases the amount of data your page has to load by 8 megabytes.

I don't think there's a good solution to CJK web fonts yet. If one existed, I think it would need to involve a font rendering technology where character shapes can be generated from strokes and radicals, instead of the literal shape of every character having to appear separately in the font.

View on HN

Why can't font files be compressed, as that would just be using a dictionary which I believe that GZip already does.

They are compressed.

Do you perchance mean "dynamically loaded, on demand"? Because there's no standard for it. Because – as usual – "good enough for Western audiences".

That sounds like an attack on westerners. Obviously westerners develop ideas for westerners first; That’s what they understand and that’s what they need. The lack of solutions for the billions of users of a writing system should not be the fault of the people who don’t use it. Sure they can do better, but they don’t deserve that tone.

I fail to see how the tone in your comment is at all appropriate for the comment you are responding to. You seem overly sensitive on this issue.

I cannot argue with „first“, but considering that this „first“ has been, what?, five decades ago, thinking that a „second“ should have emerged by now may not be totally unreasonable.

Seems like there would be demand for a font format that allows character modifiers to dynamically be applied to characters. This would allow the language to be represented digitally similarly to how it's taught in the real world, rather than as thousands of unique Unicode characters.

That is at least conceptually part of Unicode. You can encode „ü“ both as the character (one code point) and as „u“ followed by „modifier Umlaut“ (two code points).

Glyphs in fonts already make use of composite features (ü can be u + ¨, just the coordinates of the references). But readability of type can be complex, so I don't know if that's a viable solution to compose large-nonwestern fonts in a way that is natural to read. There may be very subtle differences that force the designer to decompose the parts and make modifications.

Ah! Knowing that, I bet that someone _could_ make a CJK font optimized for file size, which includes radicals by reference. It wouldn't work in every case, because radicals change size and strokes shift to make room for other strokes. In cases where the same radical appears in the same place, it seems like it would help.

But maybe that's not enough of a benefit unless there's also a way to say "okay you need to use this radical, but a bit narrower, but the strokes need to be the same width and not distorted".

The www.glyphsapp.com and www.fontlab.com font editor apps have "smart components" which do this. Sadly the OpenType format is developed very conservatively by Microsoft so these aren't part of the only widely supported font format today, despite recent additions to the format of run time interpolation technology.

The css standard for "dynamically loaded, on demand" is Unicode Range.

Reply on news.ycombinator.com