Request/discussion: FreeType as optional rasterizing backend?

[solbjorn]

I'm wondering whether it would make sense and wouldn't be too difficult to add an option to use FreeType for rendering fonts?

I'm not sure if it would produce better quality fonts, from what I understood from the comments in skb_canvas.c and skb_rasterizer.c, the current rasterizer is based on some old stb_truetype version (which lacks quality in comparison to FT, but I realize that you improved it a lot).
FreeType can also render SVG-in-OT fonts using e.g. PlutoSVG (https://github.com/sammycage/plutosvg) (I didn't try yet whether Skribidi supports SVG-in-OT).

Some example implementations:

• ImGui optional FreeType backend (including SVG-in-OT using either PlutoSVG or LunaSVG): https://github.com/ocornut/imgui/blob/docking/misc/freetype/imgui_freetype.cpp
• SFML uses HarfBuzz and SheenBidi for text shaping and FreeType for rendering: https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/Font.cpp

The reason why I prefer Skribidi over SFML is because it handles complex layouts, while SFML doesn't handle line wraps at all.

FreeType font loader also supports more formats: BZIP and GZIP compressed fonts, PNG bitmaps in fonts, WOFF fonts. For now, I use hb_face_create_or_fail_using("ft") + skb_font_collection_add_hb_font() in my WIP project, so that HarfBuzz uses FreeType to load fonts.

Any thoughts?

[memononen]

I think that would make sense. I think due to some recent developments, I might drop the canvas altogether.

One of my goals with skribidi has been to keep the dependencies low. I also want to make sure that things are reasonable "batteries included", so that it should be reasonably simple to integrate with default config.

I do not want to make freetype a default dep, but I dont mind if it is an option (ditto for PlutoSVG, even if I think colrv1 is superior :)).

Currently skribidi has these big deps: harfbuzz, sheenbidi, and libunibreak. Not long ago, kb_text_shape (https://github.com/JimmyLefevre/kb) has gotten better API and could replace most of the uses of the above (sans glyph outline access).

I think following configurations would make sense:

• min deps: kb_text_shape, stb_truetype, plus COLRv1 support for stb_tt (I have half baked version of this)
• default: harfbuzz, sheenbidi, and libunibreak, using hb-raster
• freetype: harfbuzz, sheenbidi, libunibreak, freetype (maybe using hb-raster for SVG fonts? not sure PlutoSVG has any pref here)

I think the edge FT has over HB is the light autohinting.

Skribidi has functions to turn alpha to SDF, which can be used with any of the above backends, some of them also support direct SDF rendering, but they are orders of magnitude

[solbjorn]

Oh, I like the configurations you described! I think that would fit [almost] everyone and the number of dependencies (and their weight) would still be way lower in comparison to Pango, Skia etc...

Yeah, HarfBuzz got a rasterizer and an SVG backend recently. Unfortunately, they are not available currently when building with CMake, only Meson =\
I mentioned PlutoSVG only due to that it's supported by ImGui and already has the callbacks to be passed to FreeType, so that the latter handles SVG-in-OT automatically.

[behdad]

We are merging CMake build changes for raster/vector at harfbuzz/harfbuzz#5841 would be great if you can test. @khaledhosny

Indeed, FreeType benefit over hb-raster is the hinters, including the autohinter. What hb-raster provides that I don't see mentioned here, is the COLRv1 vector color fonts, which have essentially deprecated and replaced SVG-in-OpenType color fonts. hb-raster supports both.

[solbjorn]

Oh, I see it's merged already. So I think you're correct, the options for this project could look like:

• min deps: kb_text_shape, stb_truetype, plus COLRv1 support for stb_tt (or your current rasterizer)
• default: harfbuzz, sheenbidi, and libunibreak, using hb-raster / hb-svg
• freetype: harfbuzz, sheenbidi, libunibreak, freetype for fonts and hb-raster / hb-svg for the rest

Since hb-raster/svg supersedes PlutoSVG and all SVG-in-OT backends in general (as per the comment above), it would make sense to just use it and do not pull anything else.

I'd use the third option in my project since I have all the deps already for some time. The second setup wouldn't require anything else besides what Skribidi already uses currently.