Render VARC fonts

[behdad]

This hooks up VARC fonts. I have tested it with HB cmdline tools and seems to work nicely, although, 25% slower than HB on my test CJK font.

This breaks the VARC table API in read-fonts / write-fonts. But nothing else (hopefully).

[behdad]

Using hb-draw-compare, I'm seeing some correctness issues that I'm debugging.

Four bug fixes later, I'm down to diffs of up to 0.12 font units. Investigating more.

[behdad]

Using hb-draw-compare, I'm seeing some correctness issues that I'm debugging.

Four bug fixes later, I'm down to diffs of up to 0.12 font units. Investigating more.

I tracked this down to pure float noise. I gave up investigation after a few hours. Accepting difference, since the diff is so small.

I think this is ready for review. Thanks.

[behdad]

I tracked this down to pure float noise.

Hours later... I convinced myself that the differences arises from Skrifa's FreeTypeScaler working in 26.6 whereas HB works in floats for drawing. All errors seem to be closely multiples of 1/256 font units...

There was a single-unit float value difference in the computed axes during VARC processing, but I don't think that one can have this scale of effect.

Anyway. Here's two graphs, of the max error over all glyphs, of the hanzi test font and the hangul.

[behdad]

All errors seem to be closely multiples of 1/256 font units...

I found the culprit to be cairo's 24.8 fixed type. The numbers from fontations are all multiples of 1/64, as we expect, whereas from HB they are more floaty. Because of scaling and rotation, this smaller error gets amplified, then quantized in cairo's SVG output.

I spent quite a few hours digging this rabbit hole, graphed the error (HB vs Skrifa) of all coordinates values in the hanzi VARC font I'm working with (45k glyphs). The error is behaving as we expect it given the parameters (HB in float; Skrifa in Fixed; cario I configured as 10.12 for this experiment; cairo SVG output to 17 digits of float printing.)

Here's a couple of graphs for display purposes only:

Cairo patch used:

diff --git a/src/cairo-fixed-type-private.h b/src/cairo-fixed-type-private.h
index e9f26f615..fcac865c6 100644
--- a/src/cairo-fixed-type-private.h
+++ b/src/cairo-fixed-type-private.h
@@ -59,7 +59,7 @@ typedef cairo_int128_t        cairo_fixed_96_32_t;
  * making sure that you compute a double-to-fixed magic number.
  * (see below).
  */
-#define CAIRO_FIXED_FRAC_BITS  8
+#define CAIRO_FIXED_FRAC_BITS  12
 
 /* A signed type %CAIRO_FIXED_BITS in size; the main fixed point type */
 typedef int32_t cairo_fixed_t;
diff --git a/src/cairo-output-stream.c b/src/cairo-output-stream.c
index 799a73e04..f58bea335 100644
--- a/src/cairo-output-stream.c
+++ b/src/cairo-output-stream.c
@@ -319,6 +319,8 @@ _cairo_dtostr (char *buffer, size_t size, double d, cairo_bool_t limited_precisi
 
     if (limited_precision) {
        snprintf (buffer, size, "%.*f", FIXED_POINT_DECIMAL_DIGITS, d);
+    } else if (1) {
+       snprintf (buffer, size, "%.17f", d);
     } else {
        /* Using "%f" to print numbers less than 0.1 will result in
         * reduced precision due to the default 6 digits after the

[behdad]

The rabbithole also led me to file this issue, which doesn't seem to have a significant effect on this dataset, but a bug nonetheless: #1738

[behdad]

I spent quite a few hours digging this rabbit hole

For my own reference: Gemini session: https://gemini.google.com/share/54b90c1c1d1f

[behdad]

The final verdict is that the Fixed (26.6) pipeline in Skrifa's FreeTypeScaler is hurting VARC accuracy a lot, because of the transformations applied to component shapes (scale of up to 10 in my test data), amplifying the precision error. Max error observed is 12% of a font unit on a 1000 upem. Still invisible, but not zero...

[behdad]

Tests added.