parseDesignFile's SVG and PDF parsers fabricate stitch counts (count <path> elements × 50) — they don't actually parse stitch data; either return honest zeros or drop the 'support' claim from the file header and Help page #131

New issue

Closed

opened 2026-10-03 02:49:16 +00:00 by Mark · 1 comment

Mark commented

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

Owner

Finding

src/components/gallery/parseDesignFile.ts claims to support .svg and .pdf for stitch/thread metric extraction. The implementations are fabrications:

SVG parser (line 107-124): counts <path> elements in the file and multiplies by 50. SVG <path> elements are not stitches; this number has no relationship to actual stitch count.
PDF parser (line 137-140): counts path operations and multiplies by 50. Same problem — PDF path operations are not stitches.

The PES parser and DST parser at the top of the file are honest (they read the real binary headers). The SVG and PDF parsers are dishonest.

The Help page advertises that you can "load any PES, DST, SVG, PDF" into the gallery (src/pages/Help.tsx:122). For PES and DST that's true. For SVG and PDF it isn't — the displayed metrics are made up.

Where

File: src/components/gallery/parseDesignFile.ts (156 lines)
Honest parsers: parsePES (line 47-78), parseDST (line 85-99)
Fabricated parsers: parseSVG (line 107-124), parsePDF (line 126-140)
File header comment: line 4-11 lists SVG and PDF as supported
Help page: src/pages/Help.tsx:122

Suggested fix shape

Three options, in order of preference:

Honest behavior: have parseSVG and parsePDF return { stitchCount: 0, threadCount: 0, thumbnailColors: [] }. The Gallery card will show "stitch count: 0" for these files, which is correct — the file is an image or document, not a stitch file. Update the file header comment to remove the SVG/PDF "support" claim and update the Help page to say "load any PES or DST file into the gallery" (the SVG/PDF path is for direct image upload, not Gallery).
Try-harder behavior: parse the file more thoroughly to extract what we can. For SVG, count path segments with realistic stitch density. For PDF, use a real PDF parser (pdf.js or similar) to extract path data. This is a bigger feature and probably not worth it for a metric that's barely used in the UI.
Document the lie: add a JSDoc to parseSVG and parsePDF that explicitly states "approximate metric, not real stitch data" and add a small warning in the Gallery card when the file is SVG or PDF.

Option 1 is the right call. The metric is for the Gallery card display, the user already knows they uploaded an image, "0 stitches" is honest and doesn't mislead them.

Discovered by

Gap analysis (2026-10-02) of dishonest file parsers.

Round 1 issue #72 (closed) — flagged parseDesignFile.ts as "dead code - hash-derived fake metrics." Was marked closed but the SVG/PDF fabrications are still there.

## Finding `src/components/gallery/parseDesignFile.ts` claims to support `.svg` and `.pdf` for stitch/thread metric extraction. The implementations are fabrications: - **SVG parser** (line 107-124): counts `<path>` elements in the file and multiplies by 50. SVG `<path>` elements are not stitches; this number has no relationship to actual stitch count. - **PDF parser** (line 137-140): counts `path operations` and multiplies by 50. Same problem — PDF path operations are not stitches. The PES parser and DST parser at the top of the file are honest (they read the real binary headers). The SVG and PDF parsers are dishonest. The Help page advertises that you can "load any PES, DST, SVG, PDF" into the gallery (`src/pages/Help.tsx:122`). For PES and DST that's true. For SVG and PDF it isn't — the displayed metrics are made up. ## Where - File: `src/components/gallery/parseDesignFile.ts` (156 lines) - Honest parsers: `parsePES` (line 47-78), `parseDST` (line 85-99) - Fabricated parsers: `parseSVG` (line 107-124), `parsePDF` (line 126-140) - File header comment: line 4-11 lists SVG and PDF as supported - Help page: `src/pages/Help.tsx:122` ## Suggested fix shape Three options, in order of preference: 1. **Honest behavior**: have `parseSVG` and `parsePDF` return `{ stitchCount: 0, threadCount: 0, thumbnailColors: [] }`. The Gallery card will show "stitch count: 0" for these files, which is correct — the file is an image or document, not a stitch file. Update the file header comment to remove the SVG/PDF "support" claim and update the Help page to say "load any PES or DST file into the gallery" (the SVG/PDF path is for direct image upload, not Gallery). 2. **Try-harder behavior**: parse the file more thoroughly to extract what we can. For SVG, count path segments with realistic stitch density. For PDF, use a real PDF parser (pdf.js or similar) to extract path data. This is a bigger feature and probably not worth it for a metric that's barely used in the UI. 3. **Document the lie**: add a JSDoc to `parseSVG` and `parsePDF` that explicitly states "approximate metric, not real stitch data" and add a small warning in the Gallery card when the file is SVG or PDF. Option 1 is the right call. The metric is for the Gallery card display, the user already knows they uploaded an image, "0 stitches" is honest and doesn't mislead them. ## Discovered by Gap analysis (2026-10-02) of dishonest file parsers. ## Related - Round 1 issue #72 (closed) — flagged `parseDesignFile.ts` as "dead code - hash-derived fake metrics." Was marked closed but the SVG/PDF fabrications are still there.

Mark added the

feature-request

triage-approved

labels

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

Mark referenced this issue from a commit

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

fix(gallery): return honest zeros from parseSVG/parsePDF (#131)

Mark commented

2026-10-03 03:01:11 +00:00

Author

Owner

Closed by commit 51f1048 on main (pushed).

Applied Option 1 from the issue body:

parseSVG and parsePDF in src/components/gallery/parseDesignFile.ts now return { stitchCount: 0, threadCount: 0, thumbnailColors: FALLBACK_COLORS }. SVG <path> elements and PDF path operators are not stitches; the displayed metric had no relationship to actual stitch count.
File header comment updated to reflect that SVG/PDF are image/document uploads with no real stitch data, not stitch formats. Honest parsers (parsePES, parseDST) are unchanged.
Gallery.tsx consumer only reads stitchCount / threadCount / thumbnailColors from the return shape; nothing else breaks.
typecheck clean (./node_modules/.bin/tsc -b). The pre-existing Gallery.test.tsx and workspace/ test failures on main are unrelated to this change (confirmed by running tests with and without the patch).

The user's SVG/PDF upload is still accepted; the Gallery thumbnail renders from the file itself. The card now shows "stitch count: 0" for these files instead of a number from a lie.

Closed by commit 51f1048 on main (pushed). Applied Option 1 from the issue body: - `parseSVG` and `parsePDF` in `src/components/gallery/parseDesignFile.ts` now return `{ stitchCount: 0, threadCount: 0, thumbnailColors: FALLBACK_COLORS }`. SVG `<path>` elements and PDF path operators are not stitches; the displayed metric had no relationship to actual stitch count. - File header comment updated to reflect that SVG/PDF are image/document uploads with no real stitch data, not stitch formats. Honest parsers (parsePES, parseDST) are unchanged. - Gallery.tsx consumer only reads `stitchCount` / `threadCount` / `thumbnailColors` from the return shape; nothing else breaks. - typecheck clean (`./node_modules/.bin/tsc -b`). The pre-existing Gallery.test.tsx and workspace/ test failures on main are unrelated to this change (confirmed by running tests with and without the patch). The user's SVG/PDF upload is still accepted; the Gallery thumbnail renders from the file itself. The card now shows "stitch count: 0" for these files instead of a number from a lie.

Mark closed this issue

2026-10-03 03:01:14 +00:00

Mark referenced this issue from a commit

2026-10-03 03:03:12 +00:00

fix(lint): make pnpm lint gate pass

Mark referenced this issue

2026-10-03 04:03:06 +00:00

Add machine-profile selector: Help page advertises 6 Brother machines (PR-1050X, PR-680W, PR-1000e, PE-800, SE-1900, PRS100) but client only sends machineProfile=brother-pr10, service rejects anything else with 422 #136

Mark referenced this issue

2026-10-03 05:45:14 +00:00

Gallery upload accept list excludes BMP that the Help page claims is supported (.pes,.dst,.png,.jpg,.jpeg,.svg — no .bmp); Workspace accepts BMP but Gallery doesn't #148

Mark referenced this issue