tatami_fill stitch type is collapsed to fill and original type is lost in export — digitize-adapters.ts:222 comment promises `originalServiceStitchType` but it's never set anywhere #157

New issue

Closed

opened 2026-10-03 16:05:51 +00:00 by Mark · 1 comment

Mark commented

2026-10-03 16:05:51 +00:00

Owner

Finding

mapServiceStitchTypeToWorkspace at src/lib/digitize-adapters.ts:160-175 collapses tatami_fill → fill for the workspace's stitch type model. The comment at line 222 promises: "The caller can use originalServiceStitchType (stamped on the path) to recover the source type at export time."

originalServiceStitchType is never set anywhere in the codebase. grep -rn 'originalServiceStitchType' src/ returns 1 hit: the comment in digitize-adapters.ts:222. No WorkspaceStitchObject field is set; no adapter writes it; no consumer reads it.

When the user exports a design that originally had tatami-fill regions from the service, the export sees the workspace's fill type and writes a regular fill stitch pattern. The original tatami differentiation is lost.

For PES specifically, the difference is real: tatami fill is a multi-direction fill pattern that minimizes the "pull" effect on stretchy fabrics; a regular fill is single-direction. The export's choice between them affects the stitched result.

Where

Adapter (collapses the type): src/lib/digitize-adapters.ts:160-175
Adapter (comment promising original): src/lib/digitize-adapters.ts:222
Stitch type stamping (missing): nowhere
Export consumer (would need to honor the original): src/lib/stitch-adapters.ts:toServiceStitchObjects

Suggested fix shape

Two changes:

Stamp the original type on the workspace's StitchObject. Extend the StitchObject type in src/components/workspace/types.ts with an optional originalStitchType?: "satin" | "fill" | "running" | "tatami_fill" | "jump". In fromServiceStitchObject at src/lib/digitize-adapters.ts:118-150, set originalStitchType: obj.type whenever the type is folded. The user can then see the original in the Editor's right panel ("This path was originally tatami_fill, currently rendered as fill").
Honor the original type at export. In toServiceStitchObjects at src/lib/stitch-adapters.ts, if obj.originalStitchType is set, prefer it over the workspace's type when sending to the service. The export will then correctly preserve the tatami distinction.

Severity

Medium. The Help page documents "tatami_fill" as a real service stitch type (per #130's documentation), but the export silently drops it. The user's design loses fidelity.

Discovered by

Gap analysis (2026-10-02) of stitch type handling.

#130 (closed) — filtered out jump regions. Same family; the engine's stitch-type fidelity is a related concern.
#139 (open) — Editor's "Cross Stitch" dropdown mismatch. Stitch type preservation is a broader theme.

## Finding `mapServiceStitchTypeToWorkspace` at `src/lib/digitize-adapters.ts:160-175` collapses `tatami_fill` → `fill` for the workspace's stitch type model. The comment at line 222 promises: "The caller can use `originalServiceStitchType` (stamped on the path) to recover the source type at export time." **`originalServiceStitchType` is never set anywhere in the codebase.** `grep -rn 'originalServiceStitchType' src/` returns 1 hit: the comment in `digitize-adapters.ts:222`. No `WorkspaceStitchObject` field is set; no adapter writes it; no consumer reads it. When the user exports a design that originally had tatami-fill regions from the service, the export sees the workspace's `fill` type and writes a regular fill stitch pattern. The original tatami differentiation is lost. For PES specifically, the difference is real: tatami fill is a multi-direction fill pattern that minimizes the "pull" effect on stretchy fabrics; a regular fill is single-direction. The export's choice between them affects the stitched result. ## Where - Adapter (collapses the type): `src/lib/digitize-adapters.ts:160-175` - Adapter (comment promising original): `src/lib/digitize-adapters.ts:222` - Stitch type stamping (missing): nowhere - Export consumer (would need to honor the original): `src/lib/stitch-adapters.ts:toServiceStitchObjects` ## Suggested fix shape Two changes: 1. **Stamp the original type on the workspace's StitchObject.** Extend the `StitchObject` type in `src/components/workspace/types.ts` with an optional `originalStitchType?: "satin" | "fill" | "running" | "tatami_fill" | "jump"`. In `fromServiceStitchObject` at `src/lib/digitize-adapters.ts:118-150`, set `originalStitchType: obj.type` whenever the type is folded. The user can then see the original in the Editor's right panel ("This path was originally tatami_fill, currently rendered as fill"). 2. **Honor the original type at export.** In `toServiceStitchObjects` at `src/lib/stitch-adapters.ts`, if `obj.originalStitchType` is set, prefer it over the workspace's `type` when sending to the service. The export will then correctly preserve the tatami distinction. ## Severity Medium. The Help page documents "tatami_fill" as a real service stitch type (per #130's documentation), but the export silently drops it. The user's design loses fidelity. ## Discovered by Gap analysis (2026-10-02) of stitch type handling. ## Related - #130 (closed) — filtered out `jump` regions. Same family; the engine's stitch-type fidelity is a related concern. - #139 (open) — Editor's "Cross Stitch" dropdown mismatch. Stitch type preservation is a broader theme.

Mark added the

bug

triage-approved

labels

2026-10-03 16:05:51 +00:00

Mark referenced this issue from a commit

2026-10-03 17:07:42 +00:00

fix(#157): preserve tatami_fill through editor folding — stamp originalStitchType on import, honor on export

Mark commented

2026-10-03 17:07:57 +00:00

Author

Owner

Fixed in commit 30e0daf on main (Mark/Kimi_Agent_Brother_10_Digitizing_App@30e0daf).

Implementation:

StitchObject extended with optional originalStitchType?: ServiceStitchType (src/components/workspace/types.ts).
fromServiceStitchObject now stamps originalStitchType: obj.type on every import (#157).
toServiceStitchObjects prefers originalStitchType over TYPE_MAP when set and non-jump, so a tatami design round-trips through the editor and exports as tatami_fill.
Comment in mapServiceStitchTypeToWorkspace updated (the original originalServiceStitchType promise was misleading — there was no such field anywhere in the codebase, that was the bug).

Verification:

npx vitest run — 653 tests pass across 64 files (4 new tests cover stamp-on-import + export-preserves-tatami + falls-back-to-TYPE_MAP).
npx tsc -p tsconfig.json --noEmit clean.

The fix preserves the tatami distinction that the editor folds for display; manual workspace edits have no originalStitchType so they continue to use TYPE_MAP (cross-stitch → running, motif → running, zigzag → satin).

Fixed in commit 30e0daf on `main` (https://forgejo.tail018ac4.ts.net/Mark/Kimi_Agent_Brother_10_Digitizing_App/commit/30e0daf). **Implementation:** - `StitchObject` extended with optional `originalStitchType?: ServiceStitchType` (`src/components/workspace/types.ts`). - `fromServiceStitchObject` now stamps `originalStitchType: obj.type` on every import (#157). - `toServiceStitchObjects` prefers `originalStitchType` over `TYPE_MAP` when set and non-jump, so a tatami design round-trips through the editor and exports as tatami_fill. - Comment in `mapServiceStitchTypeToWorkspace` updated (the original `originalServiceStitchType` promise was misleading — there was no such field anywhere in the codebase, that was the bug). **Verification:** - `npx vitest run` — 653 tests pass across 64 files (4 new tests cover stamp-on-import + export-preserves-tatami + falls-back-to-TYPE_MAP). - `npx tsc -p tsconfig.json --noEmit` clean. The fix preserves the tatami distinction that the editor folds for display; manual workspace edits have no `originalStitchType` so they continue to use `TYPE_MAP` (cross-stitch → running, motif → running, zigzag → satin).

Mark closed this issue

2026-10-03 17:08:00 +00:00