[antonsoo]

Transforming a short elliptic arc can turn it into a full ellipse, even with the identity matrix. This changes the geometry subsequently saved to DXF. This was found with generated CAD geometry; I do not have an affected user or production drawing.

from ezdxf.math import ConstructionEllipse, Matrix44

arc = ConstructionEllipse(
    major_axis=(1e6, 0, 0), ratio=0.7,
    start_param=5.0, end_param=5.0 + 4e-9,
)
arc.transform(Matrix44())
print(arc.start_param, arc.end_param)
# Before: 0.0 6.283185307179586
# After:  5.0 5.000000004

Remember the original full-ellipse state before adjusting axes and parameters. Transform distinct short-arc endpoints and restore a full-turn interval only for an originally full ellipse. Equal-endpoint handling stays compatible.

Validation on Python 3.12:

• Native core/integration suite: 8,362 passed, 56 skipped, 1 xfailed; pure Python: 8,054 passed, 93 skipped, 1 xfailed.
• All nine short-arc regressions fail on master; all 18 new cases pass here. Tests continue through DXF save/reload.
• Independent affine-coordinate checks repair 36 of 324 cases and retain 288 complete geometry controls. Mypy passes all 342 source files; Black passes the changed source and tests.

Tiny-arc rendering also encounters a separate angle-span tolerance problem; this change preserves the transformed geometry independently of that correction.

[mozman]

Is this a real problem you’ve actually encountered, or is it just some contrived, empty nonsense?

[antonsoo]

This came from generated CAD checks, not a production drawing or a user report. I do not have a real-world DXF affected by it. The example reproduces a partial arc turning into a full ellipse under an identity transform, but the tiny interval was chosen to exercise the tolerance boundary. I have added that origin to the description.

[mozman]

I don’t want to open the door to these kinds of theoretical problems—come back when you’re dealing with real-world issues.