This is the kind of artifacts caused by the round errors:

(it further leads to tiny little paths after overlap removal)

Interestingly, harfbuzz instancing produces the same artifacts, but AFDKO’s tx does not.

Smells like a variant of this: #2838

Smells like a variant of this: #2838

I think so (here at the instancing not merging side, though).

Not rounding at all works as well, but it gives larger file size and can expose bugs in implementations not prepared to handle fractional CFF coordinates.

Interestingly, harfbuzz instancing produces the same artifacts, but AFDKO’s tx does not.

@qxliu76

thanks for spotting this Khaled

There is probably a more clever way to doing this.
harfbuzz instancing produces the same artifacts, but AFDKO’s tx does not.

would be nice to find out how tx manages to do this while, if I understand correctly, also preserving hinting and other operators. Maybe @skef could help undestand this?

tx translates the various PostScript-like CharString formats into callbacks of this form:

struct abfGlyphCallbacks_ {
    void *direct_ctx;
    void *indirect_ctx;
    abfGlyphInfo *info;
    int (*beg)(abfGlyphCallbacks *cb, abfGlyphInfo *info);
    void (*width)(abfGlyphCallbacks *cb, float hAdv);
    void (*move)(abfGlyphCallbacks *cb, float x0, float y0);
    void (*line)(abfGlyphCallbacks *cb, float x1, float y1);
    void (*curve)(abfGlyphCallbacks *cb,
                  float x1, float y1,
                  float x2, float y2,
                  float x3, float y3);
    void (*stem)(abfGlyphCallbacks *cb,
                 int flags, float edge0, float edge1);
    void (*flex)(abfGlyphCallbacks *cb, float depth,
                 float x1, float y1,
                 float x2, float y2,
                 float x3, float y3,
                 float x4, float y4,
                 float x5, float y5,
                 float x6, float y6);
    void (*genop)(abfGlyphCallbacks *cb, int cnt, float *args, int op);
    void (*seac)(abfGlyphCallbacks *cb,
                 float adx, float ady, int bchar, int achar);
    void (*end)(abfGlyphCallbacks *cb);
    void (*moveVF)(abfGlyphCallbacks *cb, abfBlendArg *x0, abfBlendArg *y0);
    void (*lineVF)(abfGlyphCallbacks *cb, abfBlendArg *x1, abfBlendArg *y1);
    void (*curveVF)(abfGlyphCallbacks *cb,
                    abfBlendArg *x1, abfBlendArg *y1,
                    abfBlendArg *x2, abfBlendArg *y2,
                    abfBlendArg *x3, abfBlendArg *y3);
    void (*stemVF)(abfGlyphCallbacks *cb,
                   int flags, abfBlendArg *edge0, abfBlendArg *edge1);
};

Note that the hints are represented with absolute positions and are (currently) in "hint substitution" style rather than "hintmask" style (for CFF variants they're translated back into hintmask style after processing).

Random thing: if the test is CFF2, why does it have endchar operators?

It would be nice to have a fix for this in varLib.instancer. I was under the impression we are discouraged from using varLib.mutator?

yeah, it's sort of deprecated in favour of varLib.instancer. I think this PR predates CFF2 support in varLib.instancer which was added around May 2024.

I think this PR predates CFF2 support in varLib.instancer which was added around May 2024.

Ah, that makes sense. I can confirm that the same issue exists in varLib.instancer, though.

We should try converting all coordinates to absolute, do the instantiation, then revert.

We should try converting all coordinates to absolute, do the instantiation, then revert.

In the form of a charstring still I mean.