off-topic, but sbix only works reliably on mac --> https://github.com/harfbuzz/harfbuzz/issues/2679#issuecomment-1021419864
On Wed, Jan 26, 2022 at 5:43 PM Adam Twardoch (Lists) < list.a...@twardoch.com> 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: > > - https://creativemarket.com/search?q=opentype+svg > - https://creativemarket.com/romanjusdado/2950202-Wooden-Tiles-Font > - > https://creativemarket.com/SamParrett/5150302-Glory-Culture-SVG-Font-Extras > - > https://creativemarket.com/helloimgreg/2330313-Stranger-Times-OpenType-SVG-Font > 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). > > Best, > Adam > > > On Wed, Jan 26, 2022 at 5:07 PM Cosimo Lupo via FreeType development < > freetype-devel@nongnu.org> 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 >> <https://github.com/googlefonts/nanoemoji> using the following command, >> from the root of the noto-emoji >> <https://github.com/googlefonts/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. >> Cheers >> >> Cosimo >> >> On Tue, Jan 25, 2022 at 7:51 PM Werner LEMBERG <w...@gnu.org> 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 >>> enough. >>> >>> >> 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 >>> all. >>> >>> >>> Werner >>> >>
