[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MPEG-OTSPEC] COLRv1 to gray/alpha question (& color-blindness quest
From: |
Laurence Penney |
Subject: |
Re: [MPEG-OTSPEC] COLRv1 to gray/alpha question (& color-blindness question) |
Date: |
Wed, 19 Jul 2023 14:25:42 +0100 |
This is far from a complete answer to your question, but please bear in mind
that COLRv1 has been proposed and demonstrated as a solution to problems with
certain variable monochrome fonts. In particular it can be very convenient to
vary the shape of a masking contour using variations, in order to achieve
changes in overall form that are simply not possible if one varies only opaque
contours. For these fonts, the palette entry 0xFFFF is used so as to use
"current foreground colour", and that limitation itself could, in theory,
trigger certain behaviour in renderers on b/w systems.
- Laurence
> On 19 Jul 2023, at 05:01, 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
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec@lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
- Re: COLRv1 to gray/alpha question (& color-blindness question), (continued)
FT_Bitmap and FT_BitmapGlyph life cycles (Re: COLRv1 to gray/alpha question (& color-blindness question), Hin-Tak Leung, 2023/07/19
Re: [MPEG-OTSPEC] COLRv1 to gray/alpha question (& color-blindness question),
Laurence Penney <=
Re: COLRv1 to gray/alpha question (& color-blindness question), Alexei Podtelezhnikov, 2023/07/19