Rod

The "hourglass" interpretation also seems defensible but iiuc it's less implementable so to me, given COLRv1 deliberately aspires to be implementation friendly, we should take the `|r|` interpretation.

Ty for the sketch. Do we have any sense of how this model compares in size to VarC? > override the global variation space location coordinates I immediately wonder if...

> The values in the coordinates array override the global variation space location coordinates Nit: we should spell out behavior if multiple coordinates specify the same axisIndex.

(So I don't forget) In playing with the test font changing the array of coordinates to an array of offset24 to coordinate resulted in 15+% reduction in filesize because while...

Vigorously agree we need better interpolation options. Do you think it would be fair to call this a duplicate of https://github.com/googlefonts/colr-gradients-spec/issues/356?

> features that are missing in common graphics libraries +1 to this concern, definitely need to check on platform capability. If support is dodgy it might make sense to take...

https://raphlinus.github.io/graphics/2020/04/21/blurred-rounded-rects.html, @raphlinus noted distance fields fed curves might be an interesting option to explore

https://github.com/microsoft/fluentui-emoji makes extensive use of blurs and filters, some of which are not currently supported in COLRv1. It would be nice if we could build it in COLRv2. > Why...

> "Standard" stroke (SVG-style thickness-3caps-3joins) has very limited use while working with fonts (we really need more) +1, and I suspect defining a version sufficiently powerful to please type designers...

For context, our COLR v1 compiler converts strokes to equivalent paths currently.