Hi! I reached out recently on Discord asking if emoji support is something that is in scope of this binding.

I analyzed current possibilities:

• sbix – Apple format, bitmap, used only by apple emoji font AFAIK
• COLRv0 - very simple colored shapes, added by Microsoft and used in the not exactly pretty Win10 emoji font
• OT SVG - effort from Adobe and Microsoft to bring full SVGs to TTF glyphs. Heavy and wasteful but currently the simplest to implement.
• COLRv1 - arguably the future of colored fonts. It's like lightweight binary subset of SVG, allowing for all visual complexity of SVG without its quirks and parts that wouldn't be useful in fonts anyway. As of now, it is possible to parse COLRv1 information using FreeType but it requires a separate renderer. See this comment - similarly to OT SVG, rendering of COLRv1 is out of scope for FT, but maybe hooks like the ones for OT SVG might come in future. But either way, there are no public standalone COLRv1 renderers yet so might be better to wait here.

Judging from the above, I decided that OT SVG is the most worthwhile format to implement now. I like how smooth the integration with FT is.

I have a proof that this works - my toy playground for text rendering - repository. I used PlutoSVG library which is meant for usecases like this and provides ready hooks.

All the setup I had to write in my user code was:

const hooks = plutosvg.c.plutosvg_ft_svg_hooks() orelse return error.PlutoSVG;
try ft_lib.setProperty("ot-svg", "svg-hooks", hooks);

I am not exactly sure how compilation of C files in Zig looks like. Does including those 2 files means that everyone using mach-freetype will get those files in their final binary? If yes maybe there's a way to make the otsvg.h optional.

• By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.