Some valid component arrangements lead to 'interpolation-incompatible paths' error

[Hoolean]

Hello!

At Dalton Maag we've tried experimentally compiling one of our larger library fonts with the latest fontc, and have got an 'interpolation-incompatible paths' error for an arrangement of contours and components that should be valid after decomposition, and which fontmake accepts.

Reproducing

The original font is proprietary, and so we've made an independent minimal reproducer to share here, whose UFOs can also be used as the basis for an integration test if convenient :)

• ZIP containing designspace and UFO
• Original script used to construct them:

from fontTools.designspaceLib import (
    AxisDescriptor,
    DesignSpaceDocument,
    InstanceDescriptor,
    SourceDescriptor,
)
from fontTools.misc.transform import Identity, Transform
from ufoLib2 import Font
from ufoLib2.objects import Component, Contour, Point

# Create designspace with weight axis
doc = DesignSpaceDocument()
doc.addAxis(
    AxisDescriptor(tag="wght", name="Weight", minimum=400, maximum=700, default=400)
)

# Create the same glyph arrangement in two sources, one with a component offset.
for style, weight, transform in [
    ("Regular", 400, Identity),
    ("Bold", 700, Transform(dx=100)),
]:
    ufo = Font()

    # Make a glyph with contours, and two components.
    outer = ufo.newGlyph("outer")
    outer.contours.append(Contour([Point(x=0, y=0)]))
    outer.components.append(Component("inner", transformation=transform))
    outer.components.append(Component("inner"))

    # Glyph with minimal contours for use as a component.
    inner = ufo.newGlyph("inner")
    inner.contours.append(Contour([Point(x=10, y=10)]))

    ufo.save(f"{style}.ufo", overwrite=True)

    doc.addSource(SourceDescriptor(path=f"{style}.ufo", location={"Weight": weight}))
    doc.addInstance(InstanceDescriptor(styleName=style, location={"Weight": weight}))

doc.write("OuterInner.designspace")

NOTE: The same error occurs with more points - the outlines above have just been shrunk to keep the test case small

Full error

[... ThreadId(1) fontc ERROR] 'outer' has interpolation-incompatible paths
error: process didn't exit successfully: `...\fontc.exe .../OuterInner.designspace` (exit code: 1)

[rsheeter]

Thank you for the report! Edit: I see the problem, we have a bad assumption that nobody would reuse the same component with the same transform twice.

[rsheeter]

Could you retry to see if #1122 helps?

[Hoolean]

Thanks for the swift patch Rod!

I'm afraid we have strange results... the issue initially appeared fixed, but I then saw fontc crash with the original error during a later invocation.

To rule out an environment issue, I then invoked the compilation identically a consecutive 8 times, while making no other changes; this worked 6/8 times but failed 2/8 times with the original issue, and so I fear there is something non-deterministic happening now:

$ cargo run -- Font.designspace --skip-features
(pass)
$ cargo run -- Font.designspace --skip-features
(pass)
$ cargo run -- Font.designspace --skip-features
(pass)
$ cargo run -- Font.designspace --skip-features
[... ThreadId(1) fontc ERROR] '...' has interpolation-incompatible paths
$ cargo run -- Font.designspace --skip-features
(pass)
$ cargo run -- Font.designspace --skip-features
(pass)
$ cargo run -- Font.designspace --skip-features
(pass)
$ cargo run -- Font.designspace --skip-features
[... ThreadId(1) fontc ERROR] '...' has interpolation-incompatible paths

This testing used the latest commit on main (20d1e7d) and the original proprietary sources; might there be something non-deterministic happening with component order? 🔎

[Hoolean]

(over 10 invocations I can't reproduce with the minimal reproducer anymore, so the non-determinism may only become likely to cause trouble with a larger number of contours, glyphs or designspace locations)

[rsheeter]

Thanks, that's a good clue. Doubtless I did something silly with a hashset in my quick fix :)

[Hoolean]

Cheers again for the deep dive on this one Rod :) One extra clue maybe, I noticed that Readex Pro has been alternatively hopping in and out of the 'fontc failures' list on fontc_crater with the same error since the fix, in case this is useful for a reprod too

[rsheeter]

Pardon the delay, lot of OOO for Thanksgiving. I'm hoping #1150 helps?

[Hoolean]

No worries at all, thanks for the fix! I'll test straight away

[Hoolean]

As race conditions are tricksy I ran fontc double the number of times as before (16) to look for crashes; there are none now, and so I am confident that this is fixed for the original font 🍾 Thanks again Rod + Colin!