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

[Laurence Penney]

You’re right that handling alpha adds complexity. I only thought to mention it as I was responding to you.

Previous discussions on this topic have ignored alpha, and I suggest that treating alpha as always 1.0 would be the simplest way to proceed. Still, perhaps no need to restrict paint formats, they just don’t do anything interesting.

- Laurence

> On 22 Dec 2023, at 02:27, Peter Constable <pconstable at microsoft.com> wrote:
> 
> 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
>