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

[Laurence Penney]

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