back
24 comments
Nice, I've subscribed to the RSS feed. A little weird to see such old software versions being used in an article with 'modern' in its title, but I suppose you have to pick a point that's 'modern enough' to have something the majority of people can follow along with when they're all running old software too.

I wish it covered error handling a bit more than just 'exit(EXIT_FAILURE)'. FreeType must have some sort of error code or error message function.

But that's all just minor nitpicking. I like the simple and direct walkthrough of the FreeType API (and promising to include friends from the ecosystem in the future). I hope the blog series will continue!

Thanks :) I've used what was available on the latest ubuntu lts. FreeType functions return 0 (FT_Err_Ok) on success or a specific value for each function, but yes I agree that error handling could be better, maybe at the expense of terseness.
It seems that with high resolution displays, font rendering techniques are becoming less important. I remember spending days tweaking font rendering. Now with a 300 dpi display, everything looks great.
No, this is wrong. Microsoft tried it with Windows 8, getting rid of subpixel antialiasing for hardware accelerated rendering and the results were so bad that a recent update to Windows 10 began switching back. Unfortunately, Google did the same thing in Chrome and they still don’t get it and continue to insist that “it’s too hard to do it right” every time I file a bug about UI régressions that came about as a result.

macOS gets around this be aliasing the hell out of all fonts regardless of manual type hinting (or lack thereof).

OP specifically mentions his 300 dpi displays, where you indeed don't need subpixel rendering. Low-DPI displays do need to continue to use tricks to make text halfway pleasant though. Windows with its hinting philosophy and off-by-default vertical smoothing is a bit of a special case though... like every other system out there. Oh well.

> they still don’t get it and continue to insist that “it’s too hard to do it right”

What is wrong with that reply? It _is_ hard to do it correct _and_ quick.

> What is wrong with that reply? It _is_ hard to do it correct _and_ quick.

If it were anyone other than Google/Microsoft/Apple, I might accept that. Closing the bug (rather than assigning it to a future unknown release) because it’s “too hard” is ridiculous. It’s a valid concern, the results are noticeable even on hi-dpi displays, and it should be fixed (if not now, later).

I thought anti aliasing for most Macs these days was turned off since they don’t sell 1X resolutions anymore as of the MacBook Air refresh, anyways)?

Windows land doesn’t have an equivalent movement, they don’t control the hardware and so there is still a lot of 1080p in use.

They turned off subpixel antialiasing, not all antialiasing. And I’m saying on Windows the results were atrocious on hi-dpi displays, not just legacy ones.
You can turn antialiasing off in Mac
What makes this approach "modern"? What is this approach the alternative to?

As someone broadly unfamiliar with text rendering it's not clear to me. An introduction to these points would be very helpful

It's part 1, so I would hope the author plans to move on from the basics here into more modern techniques (things like subpixel anti-aliasing, ligatures, etc).
Absolutely, Subpixel AA, Kerning, Ligatures, Gamma Blending, and Emojis will be treated
Can’t wait to hear about Linux’s gamma corrected antialiasing in future posts (or lack thereof).
I agree that it's an interesting topic. On reddit one of the authors of dear imgui has some interesting thought on it: https://www.reddit.com/r/programming/comments/cfxltf/modern_...
If you use Qt 5.9+ and set the UI font to a .otf font, you get alpha-blended and gamma corrected text.
I recently needed that, too: https://github.com/Const-me/nanovg/

Also using FreeType, but unlike that article rendering on GPU, with ClearType.

No advanced typography features are supported, though.

If you are following along with gcc on Linux and continuing to get linker errors even after adding -lfreetype, try passing it as the very last argument, e.g.

  gcc `pkg-config --cflags freetype2` -Wall -Werror -o main main.c -lfreetype
While we have almost photo realistic live 3d, some text based app's are very laggy. To their defence, even though it's probably not the reason for the lag, rendering fonts are very slow and complicated.
Small nitpick: Freetype works on Windows too. So the same code can be used to render fonts there. Though it is perhaps easier to use the native DirectWrite api.
DirectWrite isn't necessarily much easier, but it has many perks you don't get from freetype - kerning, combining characters, etc - and supports hardware acceleration, which is pretty cool.

Because integrating pango/harfbuzz is so difficult I'm tempted to replace my freetype usages with DirectWrite...

What makes integration of HarfBuzz difficult?
I guess it is part 1, building up the stage to Harfbuzz/Pango.
And every other Unix. There's nothing Linux-specific about this post.
Awesome, please continue!