Hi,
This is probably both a spec question & a technical question. What is the recommendation for COLRv1 when the rendering target media is not capable of color?
OT-SVG probably has its rules inherited from SVG; or at least, it doesn't feel too odd to use SVG solely for color output, and glyf/CFF for 8-bit gray with anti-aliasing.
With COLRv0, the decisions of solid colours vs gray with anti-aliasing semi-transparent edges probably isn't too hard either.
I have finished adding COLRv1-capability to ft2-demos (that potentially means any FreeType-based system/software is then COLRv1-able), but was faced with two interesting choices:
- COLRv1 layers have alpha channels too, so one way of doing it is to throw away all the colours, and collapse all the alpha layers and draw the foreground colour (ie black) through the alpha channel.
- throw away the alpha channels, convert RGB to gray levels.
The two differ quite significantly if you have dark but transparent colours vs pale but solid colours.
In terms of implementation details, some systems might eventually choose to "lie" about legacy (non-colour) fonts as all having exactly 1 layer with a default palette of B/W, to simplify and unify APIs of accessing colour-layered and non-colour fonts?
A somewhat related question - colour fonts are used beyond emoji's. While there are 5 kinds of emoji fonts now, and most people are using one of 4... but if you check Google Fonts, there are 10 colour fonts, one is emoji, but 6 are Arabic (useful for annotating the Quran...) and 3 are Latin. So there are intentions for text fonts. A few percents of western male population is color-blind. Colour-blindness is one of the most common eye problems, after short-sightedness :-).
Screenshots at the bottom half of the web page below, and I'll continue the more technical stuff on freetype-devel.
https://github.com/HinTak/harfbuzz-python-demos/tree/master/skia-adventure