What is interaction between two colour glyphs if they overlap?

[PeterConstable]

This was raised on the AHG list. It's not really relevant for emoji fonts, but could be relevant for colour text fonts, e.g., Use Your Imagination.

Some font authors have indicated they'd like to be able to control blending of individual layers between two different colour glyphs. Supporting that generally would add significant complexity. I can think of two options that might be feasible:

• State a general expectation. E.g., if two colour glyphs overlap, implementations can have one layer above the other, and should do so consistently (e.g., glyph on the right always layered above glyph on the left). And perhaps recommend to font authors that the bounding box of a colour glyph not extend outside the side bearings.

• Perhaps at most be able to specify some simple interaction between two overlapping glyphs—e.g.,

  • If the bottom layer of one glyph overlaps the bottom layer of an adjacent glyph, then a blending (but not compositing) mode for those layers can be specified.
    \ However, While "bottom layer" is easily defined for COLR v0, it's not so simple for COLR v1, unless it's significantly restricted. E.g., can only be specified for layer 0 in a colour glyph that has PaintColrLayers at the root of its graph.

  • Taking each colour glyph as a whole, be able to specify a blending mode when overlapping an adjacent glyph, also taken as a whole.

For either of the latter "simple" interactions, either a precedence of blending modes might be needed, or a way to determine for a glyph pair which is the source that's being blended into the other (the backdrop).

[svgeesus]

glyph on the right

I assume that "later glyph in the text direction" or something like that is meant (it would be the glyph to the left in RTL, and the glyph below in vertical writing)

[PeterConstable]

Even for RTL text, glyphs have right-side and left-side connections that are absolute-direction dependent, not bidi-level dependent.

You're right to call out vertical layout as well, though. For that matter, to make things even thornier, there's a potential issue for marks that might be positioned in any of several directions relative to a base glyph.

[rsheeter]

@ctrlcctrlv proposes some concrete modes in https://github.com/googlefonts/color-fonts/issues/93

[schriftgestalt]

And perhaps recommend to font authors that the bounding box of a colour glyph not extend outside the side bearings.

That would be a very sad limitation.

Defining the drawing order is a good start.

But it really need something like grouping by z-level. Each layer/piece in the drawing stack is grouped by the z-level and those groups are drawn individually for all glyphs (first all first groups for all glyphs then the second group and so on). It doesn't need any special blending modes between those groups. Just draw them as it would be several color fonts on top of each other.

I would allow 256 levels but strongly recommend to only use 2 or 3.

[Lorp]

Even if intended to combine well together, many COLR-glyphs will have colours not in other COLR-glyphs. Do you propose inserting empty COLR-components so that all COLR-glyphs have the same z-stack? And presumably a flag to declare that layer-by-layer rendering is desired?

[ctrlcctrlv]

My proposal was that this is a purely rasterization flag.

[schriftgestalt]

I didn’t mean to group similar color (if that is what you mean). But adding an extra z level field. Maybe introduce a new grouping container. Or add add a flag to existing paint types and collect all with the same index.

[justvanrossum]

Maybe introduce a new grouping container

I like that.

• Introduce PaintColrLayersZOrdered (or a more catchy name), similar to PaintColrLayers
• It must be the root Paint of any glyph that wants to participate
• In addition the PaintColrLayers fields, it contains a uint8 Z-index array, containing a Z index per layer.
• The layers should be sorted by increasing Z index (lower Z indices are rendered before higher Z indices)
• Non-participating glyphs are rendered on top

[ctrlcctrlv]

I like PaintColrLayersZOrdered idea, but it won't fix translucent glyphs crossing.

[schriftgestalt]

True. But that are two different problems.

[ctrlcctrlv]

I was tagged so assumed this was about https://github.com/googlefonts/color-fonts/issues/93, and hoped we'd want to fix both, but if it's good enough for you to fix the one and not the other then by all means. :-)

[justvanrossum]

An additional layer of font-level information could be added, referring to the z-index, for example an alpha value associated with a layer, and compositing modes.

[schriftgestalt]

This might be related: https://forum.glyphsapp.com/t/merg-table/23901

[ctrlcctrlv]

Oh yes, very good catch! The MERG table is almost exactly what I want. But @PeterConstable would know as he works at MS—is this for antialiasing only as is claimed or should implementations do the types of merges I was looking for?

[ctrlcctrlv]

Either way my XOLR proposal is not as robust as MERG so amending MERG would be the better end goal.

[PeterConstable]

If we're going to design enhancements to handle interleaved layering across overlapping glyphs, then I think that design should also incorporate options for compositing / blending of the overlapping elements. But these ideas will need involvement from the platform engineers across major vendors that implement text rendering.