API proposal for color outlines

[dfrg]

Proposed interface for implementation of color outlines in skrifa.

rendered

[khaledhosny]

FWIW, the corresponding HarfBuzz API https://harfbuzz.github.io/harfbuzz-hb-paint.html

[dfrg]

FWIW, the corresponding HarfBuzz API https://harfbuzz.github.io/harfbuzz-hb-paint.html

Thanks for this! It looks like there are a lot of similarities, particularly around how composite nodes are handled.

[drott]

Separately, as discussed in b/301562314 and as the HarfBuzz API does it, it is probably useful to add a bitmap drawing / placement method to the ColorPen interface - but that can be a separate step.

[dfrg]

Separately, as discussed in b/301562314 and as the HarfBuzz API does it, it is probably useful to add a bitmap drawing / placement method to the ColorPen interface - but that can be a separate step.

Since landing googlefonts/fontations#609 and googlefonts/fontations#637 I have some ideas about how to support this. Let’s discuss f2f.

[drott]

@dfrg please feel free to amend, quick summary for this particular topic off the top of my head from our f2f:

• We'll add a separate interface to Skrifa as a COLRv0 and COLRv1 driver that flattens the graph, drives callbacks.
  • We'll keep the optimization for fill_path, but TBD whether we call it for PaintGlyph + PaintTransform + PaintSweep - maybe yes?
  • We'll do some normalizations where it seems useful for other 2D APIs (things that come to mind, stop normalization, 2 point linear gradients instead of 3 point.)
  • We don't deal with Path objects or actual color values on this interface, but pass glyph ids and color indices back to the client.
• We'll separate out bounds computation to a separate function, likely with passing in Scaler or a successor to Scaler, such as ScalerInstance (Skia has a stage where it does bounding box calculation before, then only later calls into drawing.)
• We don't include bitmap drawing right now, but keep it in mind to be potentially added to this interface.
• @drott will draft a PR for such a new interface and test and develop locally based on that.
• For decision on which parts we abstract behind this interface, @dfrg is offering take a look at some other 2D APIs such as Direct2D to decide what works well, and what's too Skia specific.

Among the reasons for keeping the callback interface restricted to COLR:

• In this way, we are likely able to avoid extra allocations and caching - we have a driver for COLRv0 and COLRv1 that has low memory overhead and only needs to do circularity checks in a Hashset.
• We provide more control to the application on glyph format selection, background on that: For monochromatic vs. color presentation emoji (in a hybrid font), or potentially in future CSS use cases where CSS allows glyph format selection, it's useful to have control over which glyphs are drawn, see also https://g-issues.skia.org/issues/40044044 and https://gitlab.freedesktop.org/freetype/freetype/-/issues/1142 where lack of glyph format selection in FreeType is a problem for Skia.

[dfrg]

@drott thanks for the summary. This all sounds good to me.

[drott]

Regarding the stop normalization, it turns out we can only do that level of stop normalization and preparation that does not involve color interpolation.

• For sweep: We can normalize stops to start at 0 and end at 1 by normalizing angles, changing the meaning of angles from counter-clockwise to clockwise, and "flipping" the color line if start angle is greater than end angle. The rest would be handled client side.
• For linear: We compute a new P3, so that the gradient is running from P0 to P3, and we can scale the vector from P0 to P3 so that stops are ranging from exactly 0 to 1.
• For radial: We can only do the stop normalization, but with the result that we may send a negative angle to the client side. The negative angle may involve the need to truncate a color line and interpolate a color between two color stops. Details in the discussion here: https://github.com/googlefonts/colr-gradients-spec/issues/367#issuecomment-1253038411 - I think it's good to keep the separation of leaving color interpolation to the client, as working only with color indexes here is compatible with a potential future improvement of the CPAL table.

[dfrg]

Per f2f, this sounds like a great compromise to provide as many useful transformations as possible without doing color interpolation.

Discussion also touched on using a SmallVec like container to avoid some allocations for the color stop array. Skrifa already has one that might be useful, possibly with modifications.