So there is a small issue with transparent edges; you can see that they slightly darker than they should be. This is because FreeType produces colours with premultiplied alpha. By default, we use the "plain" pixel format, which does non-premultiplied colours into a non-premultiplied buffer. Agg does have multiple blender options, but those are: 1) plain colours to plain buffer, 2) premultiplied colours to premultiplied buffer, and 3) plain colours to premultiplied buffer. Unfortunately, that means it doesn't have the blender we need, premultiplied colours to non-premultiplied buffer.

The simplest fix is to drop the buffer into Pillow and have it un-premultiply and then draw with our normal blender, but this may be a bit inefficient.

OK, I have now moved all that calculation to the Agg side by modifying RendererAgg::draw_image to be a bit more generic. Annoyingly, the way a format is described in Agg is a bit messy. A pixel format is a blender + rendering buffer, and a blender is a class that does mixing over a colour format (i.e., 8-bit bytes) + an order.

The original code has a pixel format that is 8-bit-per-component RGBA with plain (non-premultiplied) colours blended to a plain buffer. For the image, we attach the same pixel format since everything is intended to be the same.

For colour fonts, FreeType generates a premultiplied BGRA image. We can't just attach an order directly to a buffer, so we need a new pixel format for the source image that specified BGRA. Confusingly, the blender there is superfluous because we aren't blending anything onto the image. Instead, a blender for the destination needs to be used with the destination order. The one that we have is plain->plain, so we have to attach a new one that does premultiplied->plain (with a new implementation since Agg doesn't have that one.)

I was hoping to just pass in the source pixel format and somehow decompose that internally, but couldn't figure out how to do that in C++, so I resorted to passing in two pixel formats to get the correct order+blender. I've also not actually checked the implementation with a complex clip path, as that is generally not working with text anyway.

Now, the antialiased edges are correct on an opaque background:

as well as a transparent background:

Two remaining questions:

1. For plain->plain, we apparently have a fixed_blender_rgba_plain to increase precision; the blender_rgba_pre_plain that I wrote is based on Agg's premultiplied->premultiplied routine instead. I am uncertain whether I also need to apply a similar fix for precision purposes.
2. I don't know how best to test this; maybe Niklaus would be reasonable here? It's about 25k for the COLRv0 font though 67K for the SVG font (but we don't support the latter).

On a side note, if you output PDF, then all of the fonts in the test image above work, so at least the embedding is correct.

Impressive!
Regarding premultiplication conversions: it appears that agg implements demultiplication with plain divisions (in rgba8T::demultiply). I also implemented (manual) conversions for mplcairo (as cairo uses premultiplied throughout), and back then I noticed it was much faster to precompute the (premul, alpha) -> (demul) table once (there's only 65536 entries with single bitdepth, which very reasonable) and use lookups instead. (https://github.com/matplotlib/mplcairo/blob/8bb74e0c25c6ac0248f6d507db09b67a953bbc1f/ext/_mplcairo.cpp#L1860-L1867) Obviously it doesn't have to be done here, but perhaps something to keep in mind (was there any place where we had to do any of this dance with agg previously?).

was there any place where we had to do any of this dance with agg previously?

Probably not? We usually do plain->plain blending. I guess there's a division here, but not for demultiplying alpha:

I've now added a test using a subset of OpenMoji Color in COLRv0 format. I forgot that Niklaas was just a sampler for a proprietary font, so that was a no-go.

Rebased on top of #31085 as I think it makes this simpler to review. It also should mean that this is now independent of the font work going in for test image changes (other than requiring the new FreeType, of course).