Support COLR fonts

[liZe]

A few notes:

• It works with Noto, to be tested with other fonts.
• PDF renderers are not all happy with the result:
  • Chrome is perfect,
  • Firefox is a bit slow and misses some gradients,
  • Epiphany is randomly broken,
  • Poppler is ultra slow but renders correctly,
  • Ghostscript fails with an endless loop.
• The code relies on Harfbuzz 13+ and Harfbuzz-Vector, that is not packaged for Debian/Ubuntu for example,
• So… it can’t be tested on GitHub CI.

We have to do better before merging.

[liZe]

The performance problem and rendering glitches are caused by radial gradients. I fixed a problem of SVG rendering, but there’s nothing wrong in the generated PDF as far as I can tell.

Chrome is OK. Firefox misses some gradients depending on the PDF zoom level, that’s definitely a problem in Firefox. Gradients are broken in Epiphany. Poppler is a bit slow but gives the correct rendering.

Ghostscript is probably the best tool to understand why renderings can be long. Generated Emojis include very large rectangles with gradients, but these rectangles are clipped by masks or by the image boundaries. Unfortunately, the clipping region isn’t used to reduce the rendering time. Here are examples:

<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
  <defs>
    <radialGradient id="gr0" gradientUnits="userSpaceOnUse"
                    cx="50" cy="50" r="50"
                    fx="50" fy="50" fr="25">
      <stop offset="0" stop-color="red"/>
      <stop offset="1" stop-color="black"/>
    </radialGradient>
  </defs>
  <rect x="0" y="0" width="100" height="100" fill="url(#gr0)"/>
</svg>

This is rasterized easily by Ghostscript. But setting a rect size of 1000 multiplies the rendering time by ~4, and 10000 by ~100. The rectangle is clipped by the image size, so the rendering is exactly the same and Ghostscript could be optimized to avoid useless work.

The problem is that emojis, at least in Noto, contain a lot of these clipped elements with gradients. Tweaking font size gives better cases sometimes, but we don’t want workarounds that would probably be different for different fonts, just because rendering tools are not optimized.

As Chrome (probably the most widely used PDF reader) seems to be OK, I guess that we can accept this limitation. I’ll test Adobe Acrobat Reader too.