[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: test font with both SVG and COLR table

From: Roderick Sheeter
Subject: Re: test font with both SVG and COLR table
Date: Wed, 26 Jan 2022 10:02:39 -0800

Strikes me we should consider adding a PaintBitmap to COLRv1. That would make it possible for us to convert many (though not all) fonts between COLRv1 <=> ot-svg. Looking at my own little slice of the world I could imagine onboarding a COLRv1 font to Google Fonts and if a Safari user happens to try to view a page using it they receive an ot-svg equivalent. The font file they get will be much bigger but it will Just Work.

On Wed, Jan 26, 2022 at 9:48 AM Cosimo Lupo <> wrote:
off-topic, but sbix only works reliably on mac -->

On Wed, Jan 26, 2022 at 5:43 PM Adam Twardoch (Lists) <> wrote:
Apologies for a bit off-topic:

BTW, given that some folks at Apple don’t seem to be great fans of COLRv1, while Google isn’t a great fan of SVG, chances are that we’ll see the phasing out of "sbix" and "CBDT", but both COLRv1 and SVG will stick around — also because SVG allows bitmaps. Check out: 

of su
This stuff is all bitmap-based, it’s all released fonts available on the market, and for now, they’re OT+SVG only. COLRv1 won’t replace them. 

This means that we’ll keep seeing OT+SVG fonts, OT+COLRv1 fonts and quite possibly _hybrid_ OT+SVG+COLRv1 fonts, which kind of make sense if the font vendor wants to make the users’ life simple. 

I’m just saying — the hybrid OT+SVG+COLRv1 font is not an eccentricity, I think it’ll be reality — especially if font editor vendors like FontLab make creation of such hybrids easy. 

With 4 separate color font flavors, the market acceptance was low (but still, people have made many such fonts). But as soon as those flavors are down to just 2, I think both will stick around. (Though I do see a reason for sbix to also exist, especially in Apple’s own HEIC flavor, not PNG, which they use on iOS).


On Wed, Jan 26, 2022 at 5:07 PM Cosimo Lupo via FreeType development <> wrote:
Hi Werner and all,
please find attached a test COLRv1 + SVG font, containing only one color glyph ✍ "WRITING HAND" (U+270D) emoji.
The font was built using nanoemoji using the following command, from the root of the noto-emoji repository:

$ nanoemoji --color_format=glyf_colr_1_and_picosvg --keep_glyph_names --pretty_print --family "Noto Color Emoji COLRv1 And SVG" svg/emoji_u270d.svg

Let me know if that is what you are looking for.


On Tue, Jan 25, 2022 at 7:51 PM Werner LEMBERG <> wrote:

> Do you still need such a test font with SVG and COLR in it? I guess,
> we can make one if it's needed.

This would be still very helpful, yes.  I think it would be helpful
for for fuzzing, too.  A single glyph (besides '.notdef) would be

>> The question doesn't arise for serious `COLR` handling, as
>> described above.  In case of the convenience `COLR` rendering,
>> `SVG` takes precendence.
> I think the table preference decision should be made by the
> application, or in the FT_LoadGlyph then with flags that allow
> separate selection?

Since the convenience stuff is tagged as experimental, and Alexei has
some serious concerns I probably won't change anything right now.

> FWIW, overall, I think if a font has COLRv1 and SVG, COLRv1 should
> have preference as it enables variable capabilities.

This is up to the application; there is no issue w.r.t. precendence at


reply via email to

[Prev in Thread] Current Thread [Next in Thread]