[MPEG-OTSPEC] [EXTERNAL] Re: monochrome compositing via COLR w/o CPAL

[Peter Constable]

Hi Laurence:

> Monochrome COLR (v0 and v1) fonts work perfectly well today in COLR-supporting environments

That's COLR supporting environments in which 2D graphics operations need to be supported.

> since all of them allow setting of alpha; and setting and varying alpha makes sense in monochrome fonts

That is adding significant complexity and resource requirements to monochrome rasterization. The TrueType (and, I'm sure, CFF) rasterizer allows for fast processing with limited resources: grid lines are scanned and bi-level pixels (1 bit per pixel) are set, plus simple Boolean operations on the pixel values. For what you're suggesting, the implementation will needs to use 8 bits per pixel with integer arithmetic operations on pixel values (including multiply and divide) instead of simple boolean operations.

I'm not an engineer that has to maintain a rasterizer implementation, but as a Technical PM I'm suspicious that that kind of change is what would be accepted for monochrome rasterization in a broad range of environments. It's because of that I want to make sure it's called out what is being suggested.


As for the additional problem I called out, this came to my mind after it was suggested that COLR without CPAL could be a heuristic for a rasterizer to determine that it should use the COLR table to construct composite glyphs. You suggest there isn't an issue if presence of CPAL is irrelevant: the rasterizer can always use COLR to construct composite glyphs, and simply replace any palette index values with Oxffff. With that assumption, then indeed a font could support both colour and monochrome rendering while using COLR composites in both cases. But that's built on a premise that the full capabilities of COLR (minus other colour values) should be available in monochrome rasterization. I'm not sure we really would want to go there.



Peter

-----Original Message-----
From: Laurence Penney <lorp at lorp.org> 
Sent: Thursday, December 21, 2023 4:36 PM
To: Peter Constable <pconstable at microsoft.com>
Cc: MPEG OT Spec list <mpeg-otspec at lists.aau.at>
Subject: [EXTERNAL] Re: [MPEG-OTSPEC] monochrome compositing via COLR w/o CPAL

Hi Peter,

Some comments inline...

> On 21 Dec 2023, at 23:10, Peter Constable <pconstable at microsoft.com> wrote:
> 
> During the AHG meeting there was mention of the idea of supporting additional compositing modes than ‘glyf’ currently supports by using a COLR table. The suggestion was that, if there is a COLR table but no CPAL table, then that would be an indication for a rasterizer that it should use the COLR table to get composite glyph descriptions.
>  It was mentioned that, without a CPAL, there couldn’t be an colour references (COLR doesn’t have any default colours). That means that various Paint table formats can’t be used: Paint(Var)Solid, Paint(Var)LinearGradient, Paint(Var)RadialGradient, and Paint(Var)SweepGradient.

I have been assuming that, in these fonts, all leaves of the DAG would terminate in a PaintSolid table, with paletteIndex set to 0xffff (=currentColor). In fact, keeping paletteIndex at 0xffff in all cases, it makes sense to allow all 4 (8 including variable) of the terminating paint tables, since all of them allow setting of alpha; and setting and varying alpha makes sense in monochrome fonts. Renderers should be able to handle alpha because of antialiasing.

> But that leaves several other formats to be supported. It’s worth calling out that there’s a fair amount more functionality — hence complexity — than ‘glyf’ composites:
>  
>     • PaintComposite has several compositing modes — the benefit that is the motivation behind this proposal. But note that it also supports several colour blending modes that involve more than Boolean operations on pixel values.
>     • Twenty transform formats (granted, most of these are storage optimizations of a matrix, but they are distinct formats to be parsed)
>         • Paint(Var)Transform, Paint(Var)Translate, Paint(Var)Scale, Paint(Var)ScaleAroundCenter, Paint(Var)ScaleUniform, Paint(Var)ScaleUniformAroundCenter, Paint(Var)Rotate, Paint(Var)RotateAroundCenter, Paint(Var)Skew, Paint(Var)SkewAroundCenter
>     • Layers (PaintColrLayers)
>     • Embedding of glyph descriptions via PaintColrGlyph  Even without 
> colour references a COLR glyph description is still an acyclic directed graph that needs to be walked, with all the available types of operation to be executed.
>  My initial reaction to the COLR w/o CPAL idea is that there’s a fair amount more complexity to be added to monochrome glyph rasterization that might not be desirable for all rasterizer implementations.

It seems to me that the only issue is when a CPAL-less font encounters paletteIndex != 0xffff. In such cases the easiest thing to do would be to force it to be 0xffff internally, i.e. paletteIndex is ignored if there is no palette.

>   After the AHG meeting, it also occurred to me that this proposal would build in a significant limitation for many _colour_ fonts! I think it’s fair to assume that most colour fonts are intended to also provide legible monochrome display — i.e., most colour fonts are colour/monochrome hybrids. But in that case, there is a CPAL table present, and so COLR could not be used to provide additional compositing modes for monochrome rendering. IMO, that’s a pretty significant limitation that we shouldn’t settle for.

I don’t think there is an issue here. Monochrome COLR (v0 and v1) fonts work perfectly well today in COLR-supporting environments, as long as you use paletteIndex=0xffff everywhere. Just there’s a dummy CPAL table that the spec forces on the maker.

- Laurence