Bug: PES export writes duplicate trailing thread for 2-color designs (3 thread entries instead of 2) #8
Labels
No labels
blocked:needs-attention
blocked:needs-decision
bug
feature-request
in-progress
needs-decompose
quickfix
triage-approved
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Mark/easystitch-service#8
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
When a design has N color blocks, the exported PES contains N+1 threads — the last entry is a duplicate of the first color with zero stitches. Verified via pyembroidery round-trip:
Root cause
app.py:251-264only updatesprevious_colorafter writing aCOLOR_CHANGErecord. When the color stream returns to the first color or simply ends, no final settlement happens, and pyembroidery infers an extra empty trailing thread.Suggested fix
After writing all stitch objects, if
previous_coloris non-None, emit a final dummyCOLOR_CHANGE(orEND) to settle the thread table. Or de-dup empty trailing threads in the writer.Reproduction
Severity
MEDIUM — Brother PR10 reads and sews correctly despite the extra thread entry, but the file is non-canonical and may confuse other tools (Wilcom, Embrilliance, conversion pipelines).