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
<ht...@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
