Context
README.md and CONTRIBUTING.md both send readers to a supported-scanner matrix. It does not exist — git ls-files docs returns only competitor-gaps.md and macos-scanning-apis.md.
"Will my scanner work?" is the first question a Mac card seller asks, and the doc doubles as the contribution surface: users paste their --inspect output and the matrix grows without the maintainer needing to own every device.
What to change
New docs/SUPPORTED-SCANNERS.md. All the baseline data is already in the tree and can be transcribed without a scanner:
Sources/ScanDeckScanner/ScannerInventory.swift — SupportedScanner.usbIdentities: 0x04c5:0x15ff (Fujitsu-branded) and 0x05ca:0x03d8 (Ricoh-branded), both the fi-8170Sources/ScanDeckCore/PFUCardScannerProfile.swift — the four vendor-feature selections: cropping (overscan), multifeed detection off, blank-page skip off, pre-pick offSources/ScanDeckScanner/ImageCaptureScannerProbe.swift — the hard capability gates the probe actually checks
Define the columns from those gates, so a submitted dump can be scored rather than just filed. At minimum: duplex, 600 dpi, 24-bit RGB, a fixed/settable scan area, and an overscan-equivalent cropping mode.
Include a "Reported, unverified" section so a datapoint from someone else's scanner has somewhere to live before anyone has confirmed a full pass on it — the distinction between probes clean and known to publish correct output is the whole point and should be visible in the table.
Link it from README's "About scanner support" section, which already makes the pitch and currently points at CONTRIBUTING.md instead.
How to verify
swift run scandeck-m0 --list # sanity-check the fi-8170 rows if you have one
swift test -c release
Mostly this needs a careful read of the three files above. If you have a different scanner, open a hardware datapoint issue too — that is the first row of the "Reported" table.
See CONTRIBUTING.md. No scanner needed to write it.
Context
README.md and CONTRIBUTING.md both send readers to a supported-scanner matrix. It does not exist —
git ls-files docsreturns onlycompetitor-gaps.mdandmacos-scanning-apis.md."Will my scanner work?" is the first question a Mac card seller asks, and the doc doubles as the contribution surface: users paste their
--inspectoutput and the matrix grows without the maintainer needing to own every device.What to change
New
docs/SUPPORTED-SCANNERS.md. All the baseline data is already in the tree and can be transcribed without a scanner:Sources/ScanDeckScanner/ScannerInventory.swift—SupportedScanner.usbIdentities:0x04c5:0x15ff(Fujitsu-branded) and0x05ca:0x03d8(Ricoh-branded), both the fi-8170Sources/ScanDeckCore/PFUCardScannerProfile.swift— the four vendor-feature selections: cropping (overscan), multifeed detection off, blank-page skip off, pre-pick offSources/ScanDeckScanner/ImageCaptureScannerProbe.swift— the hard capability gates the probe actually checksDefine the columns from those gates, so a submitted dump can be scored rather than just filed. At minimum: duplex, 600 dpi, 24-bit RGB, a fixed/settable scan area, and an overscan-equivalent cropping mode.
Include a "Reported, unverified" section so a datapoint from someone else's scanner has somewhere to live before anyone has confirmed a full pass on it — the distinction between probes clean and known to publish correct output is the whole point and should be visible in the table.
Link it from README's "About scanner support" section, which already makes the pitch and currently points at CONTRIBUTING.md instead.
How to verify
Mostly this needs a careful read of the three files above. If you have a different scanner, open a hardware datapoint issue too — that is the first row of the "Reported" table.
See CONTRIBUTING.md. No scanner needed to write it.