FT_Bitmap and FT_BitmapGlyph life cycles (Re: COLRv1 to gray/alpha question (& color-blindness question)

[Hin-Tak Leung]

The technical question. I have worked out how to "hijack" the current system- basically wrapping "FT_Glyph_To_Bitmap()" with my "*_Extended()" version, which calls "FT_Glyph_To_Bitmap()" then over-write the bitmap with Skia's help before returning.

Since this sort of depends on the font being regarded as 'coloured', so I was over-writing SVG rendering in the dual-table font (the rsvg bug turns out to be a blessing - I am overwriting a "wrong" SVG-generated b/w RGBA buffer with COLRv1 colours, so I know it is working when the bug "disappears"), and overwriting a 8-bit gray buffer with grays in a modified font without SVG table. But ideally I'll like to throw it away and do my own things - this is most important when the dimension of COLRv1 rendering is one pixel different from glyf or SVG rendering.

(It is rare but it does happen). I don't seem to be about to create my own bitmap - it always crashes - so my question is exactly that:

How to throw away the bitmap resulting from running FT_Glyph_To_Bitmap(), and replacing it with a new one that may be one pixel large or smaller in width and/or height?

On Wednesday, 19 July 2023 at 05:01:50 BST, Hin-Tak Leung <htl10@users.sourceforge.net> wrote:

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