Hacker News Reader

Comment by barbariangrunge | Hacker News Reader

I wrote an openGL font renderer once. It was a lot of fun. Bezier curves are such an elegant technique. The difference between what I wrote and what you'd use in a proper environment is pretty big, but I recommend it sometime.

Fonts are pretty much just third or fourth degree beziers, plus a way to shade between the lines iirc (i may have my terminology wrong). Try it out sometime, I did my curves using tessellation shaders.

Btw, you'll never find a better guide on beziers than here:

https://pomax.github.io/bezierinfo/

View on HN

I work for a major foundry and fonts are ludicrously complex for a ton of reasons, but for the most part TTFs use quadratics, but our designers exclusively use cubics (postscript outlines) at design time and there is a conversion process to fit them as quadratics. On ultra lowend devices, having quadratics renders faster and the hinting works better, but if you're a designer consuming fonts, you should stick with OTFs as it is what the designer intended.

I am an end-user, but I pay a lot of attention to rendering methods and hinting so I consider myself educated on the subject.

Saying OTF is tricky.. because OTF file format can be postscript outlines OR truetype outlines and you don't know what is inside until you check.

Sticking to what the designer intended is not always the right approach because in the end, it's about the end-user experience. If your output medium is a printing press, absolutely, every time what the designer intended. If your medium is a screen then the resolution and how the OS works matters. Using IBM Plex Sans on a standard definition screen as an example, the unhinted OTF will end up at some sizes squishing the letters into the wrong shapes and render lighter while the TTF will render the shapes better due to better grid fitting and darker. Basically and unfortunately, you have to test it for every environment and not assume that a given file is the best viewing experience.

I dislike AA in general as a blurry mess (and disable it on my desktop, which yes, does mean I have to hand-pick fonts that were hinted for no-AA), and fail to understand why as more and more high-DPI screens are used that AA is still being used seems redundant and counter-intuitive.

If you consider cjk, you need almost 4x dpi for really complex character like 龜 to actually looks like what it is intended.

If it is a phone with 6 inch 2k or 4k screen. Then probably you are right, you don't need AA.(Honestly I don't know if my phone have aa enabled or not, because I can't really see the pixel with bare eye) But for 27 inch 4k screen, it is still not enough.

BTW. It's really obvious for a CJK user when the AA went wrong for whatever reason. Take an example, this issue: https://github.com/marticliment/ElevenClock/issues/241

I don't know CJK, but I enjoyed the tough example you showed me. First I looked at a hand-drawn calligraphy example of it so I could see what it is supposed to look like, then I looked at how some fonts render it on my system and it's pretty grievous for most (I can see strokes are missing, etc.)

Probably the best font for this character that is available on my system (AA is off and I don't have a hi-dpi display) is "MS Gothic". Strokes seem darker, present and clearly rendered. Do you like this font?

> for really complex character like 龜

*repeatedly zooms/unzooms Firefox* Aw man, and I just finished convincing myself that my new 3440x1440 screen had "enough" resolution too. :p

That said, perhaps this particular scenario actually embeds an implicit/unreliable assumption: That for some reason both "A" and "龜" ought to be viewed by humans at about the same size.

I mean, imagine a hypothetical language where the required display-size of a glyph is a square patch 4x the area of "Hello", but the larger size is justified by how it also contains 4x more information, like "greetings / very-respectful / spouse of my son." The writing system just has a different decisions about how to chunk/group detail.

> That said, perhaps this particular scenario actually embeds an implicit/unreliable assumption

Yes and No.

Yes, you can literally read a Chinese sentence even 50% of the stroke is blurry. (Or it is simply all blurry,assume you don't cover some key character to the point that it is completely unidentifiable.)

No, it's not really a pleasant reading experience.

After update the macos to that version using grey-scale AA by default.(It used to be subpixel AA) The first thing I noticed is every chinese character is blurry on the 1080p external screen. I really have no idea why apple think that will be a good idea. Is people don't use 1080p screen now? Or probably there isn't a CJK apple engineer at all?

> for really complex character like 龜

This tells me that I need to change my CJK font fallback. I see a character, but depending on what font-renderer I use, changing the font-size either doesn't change the size of that glyph, or resizes the original glyph pixel-by-pixel. Clearly whatever font it is falling-back to is not a proper outline-font...

[edit]

Does anyone have a good way to determine what font is used to render a particular character in any linux application? The best I've come up with is grepping pmap for font files...

If you use a normal browser like Firefox or Chrome the settings for fonts are there in the browser settings. Firefox will let you override the page's choices, Chrome won't. Zoom works for both.

> Does anyone have a good way to determine what font is used to render a particular character in any linux application?

You could take a screen-snip and run it through a font type identifier.

FWIW, pmap showed me it was using unifont, and installing the Noto CJK makes the glyph much improved (though illegible at default sizes).

Firefox: dev tools, Inspector tab, Fonts panel, Fonts Used.

You're kind of cheating with this old, mostly unused character (it was simplified to 亀). But the point stands, because there are plenty of common characters that can be just as unreadable.

Your simplified variant of 龜 appear to be used in Japanese kanji, but the "old, moetly unused" version is still used in places using Traditional Chinese like Taiwan and Hong Kong.

Erf, I don't know why, but somehow I thought you were talking about Japanese specifically.

Even your `simplified` example (assume no one using 龜 now) can have trouble on a 4K screen. the horizontal line is the 田 structure of this character is somehow not vertically centered on my firefox. (given it should have enough space to)

https://i.imgur.com/You0nKL.pngA

BTW: I am a Taiwanese, so I literally use that character.

>Saying OTF is tricky.. because OTF file format can be postscript outlines OR truetype outlines and you don't know what is inside until you check.

it is true .ttf fonts. .otf is always cubic

No, OTF supports both TrueType font outlines [0] (quadratic only) and CFF/CFF2 outlines [1] (cubic or quadratic). In fact, CFF is relative rare in the wild.

[0] https://learn.microsoft.com/en-us/typography/opentype/spec/g...

[1] https://learn.microsoft.com/en-us/typography/opentype/spec/c...

If you're more video oriented, a quite nice overview can be found on YouTube:

https://www.youtube.com/watch?v=jvPPXbo87ds

Reply on news.ycombinator.com