Service returns 5 stitch types (satin, fill, running, tatami_fill, jump) — editor exposes 3 and silently maps jump→running, which is wrong (jump stitches are connector lines, not real stitches) #130

New issue

Closed

opened 2026-10-03 02:49:16 +00:00 by Mark · 0 comments

Mark commented

2026-10-03 02:49:16 +00:00

Owner

Finding

The service's Region.stitchType is "satin" | "fill" | "running" | "tatami_fill" | "jump". The editor's stitch-type dropdown offers only 3 options: Satin, Fill, Running.

The client silently maps tatami_fill → fill and jump → running via mapServiceStitchTypeToWorkspace (src/lib/digitize-adapters.ts:160-175). The user has no way to know which a region originally was.

For tatami_fill, the mapping is probably fine — tatami is a fill variant. The user wouldn't notice.

For jump, the mapping is wrong. Jump stitches are not real stitches; they're connection lines the machine makes between non-adjacent regions without laying thread. Treating them as running and exporting them as actual stitches would produce a non-stitchable file: the user would have visible lines of running thread connecting their design elements, which the design never called for.

Where

Service type: src/lib/easystitch-client.ts:38 (Region) and :48 (StitchObject)
Silent mapping: src/lib/digitize-adapters.ts:160-175 (mapServiceStitchTypeToWorkspace)
Editor dropdown: src/components/editor/EditorRightPanel.tsx:294-296 (the 3-option select)
Help page documentation: src/pages/Help.tsx:78-95 documents 9 stitch types (Satin, Fill, Running, Cross-Stitch, Motif, Zigzag, Bean, Applique, Stem) — only 3 are exposed in the editor

Suggested fix shape

Two parts:

Don't map jump to running on the client side. Either:
- (a) Filter jump stitches out of the response before they reach the editor (correct for export — they shouldn't be stitches). Then handle the visual rendering of jump paths differently if the user wants to see them.
- (b) Preserve the original jump type in the workspace model and add it as a non-stitchable "connector line" that the renderer draws as a thin dashed line, never exported as a stitch.
Preserve tatami_fill as its own type or fold it to fill correctly. If folding, the editor should at least remember the original was tatami (stamped in the path's metadata) so the export can decide whether to emit tatami or regular fill stitch geometry.

The simplest fix that prevents user harm: filter jump regions from the response. Jump stitches are an export concern, not a workspace concern. The Workspace doesn't need to show them. The export can either add them back as no-thread connector lines in the PES, or rely on the machine's auto-jump behavior (most modern machines handle this).

Discovered by

Gap analysis (2026-10-02) of unreached service response data.

Help page documents 9 stitch types; only 3 are exposed in the editor. The 6 missing (Cross-Stitch, Motif, Zigzag, Bean, Applique, Stem) are a separate, larger feature.

## Finding The service's `Region.stitchType` is `"satin" | "fill" | "running" | "tatami_fill" | "jump"`. The editor's stitch-type dropdown offers only **3** options: Satin, Fill, Running. The client silently maps `tatami_fill → fill` and `jump → running` via `mapServiceStitchTypeToWorkspace` (`src/lib/digitize-adapters.ts:160-175`). The user has no way to know which a region originally was. For `tatami_fill`, the mapping is probably fine — tatami is a fill variant. The user wouldn't notice. For `jump`, the mapping is wrong. Jump stitches are not real stitches; they're connection lines the machine makes between non-adjacent regions without laying thread. Treating them as `running` and exporting them as actual stitches would produce a non-stitchable file: the user would have visible lines of running thread connecting their design elements, which the design never called for. ## Where - Service type: `src/lib/easystitch-client.ts:38` (Region) and `:48` (StitchObject) - Silent mapping: `src/lib/digitize-adapters.ts:160-175` (`mapServiceStitchTypeToWorkspace`) - Editor dropdown: `src/components/editor/EditorRightPanel.tsx:294-296` (the 3-option select) - Help page documentation: `src/pages/Help.tsx:78-95` documents 9 stitch types (Satin, Fill, Running, Cross-Stitch, Motif, Zigzag, Bean, Applique, Stem) — only 3 are exposed in the editor ## Suggested fix shape Two parts: 1. **Don't map `jump` to `running` on the client side.** Either: - (a) Filter jump stitches out of the response before they reach the editor (correct for export — they shouldn't be stitches). Then handle the visual rendering of jump paths differently if the user wants to see them. - (b) Preserve the original `jump` type in the workspace model and add it as a non-stitchable "connector line" that the renderer draws as a thin dashed line, never exported as a stitch. 2. **Preserve `tatami_fill` as its own type or fold it to `fill` correctly.** If folding, the editor should at least remember the original was tatami (stamped in the path's metadata) so the export can decide whether to emit tatami or regular fill stitch geometry. The simplest fix that prevents user harm: filter `jump` regions from the response. Jump stitches are an export concern, not a workspace concern. The Workspace doesn't need to show them. The export can either add them back as no-thread connector lines in the PES, or rely on the machine's auto-jump behavior (most modern machines handle this). ## Discovered by Gap analysis (2026-10-02) of unreached service response data. ## Related - Help page documents 9 stitch types; only 3 are exposed in the editor. The 6 missing (Cross-Stitch, Motif, Zigzag, Bean, Applique, Stem) are a separate, larger feature.