Apple driver (macOS) silently ignores custom page sizes, scans Letter instead

[rqahmad]

On macOS with the Apple (ImageCaptureCore) driver, any custom page size is discarded and
the scan is performed at Letter (8.5 × 11 in) instead. There is no error, no warning, and
no log entry — the scan reports success. Enumerated sizes (Letter, Legal) work correctly,
which makes the failure specific to the custom-size path.

This matters for long-paper scanners. My scanner is rated for 8.5 × 200 in, but on macOS
nothing longer than Legal is reachable, and a user asking for 36 in gets an 11 in scan with
no indication that anything was truncated.

Environment

• NAPS2 8.3.2+70662a3160986975fb3abb3cd67a0caaa6f63290 (from NAPS2 console --help)
• macOS 26.5.2 (build 25F84), Apple Silicon (arm64)
• Driver: apple
• Scanner: Ambir ImageScan Pro 830ix, USB 0x20EC:0x830A, connected directly (no hub)
• Vendor ICA driver: /Library/Image Capture/Devices/Ambir Scanner.app v1.0.1.21 (universal binary)
• Scanner rated by the manufacturer at 8.5 × 200 in max scan area

Steps to reproduce

Both the GUI profile path and the CLI path fail identically.

Via profile — set a profile to the Apple driver, Feeder source, 300 dpi, and a custom
page size of 8.5 × 36 in, then scan.

Via CLI:

NAPS2 console --driver apple --device "Ambir" --source feeder \
              --pagesize 8.5x36in --dpi 300 -o out.pdf -v

CLI output reports complete success:

Scanned page 1.
1 page(s) scanned.
Exporting...
Successfully saved PDF file to out.pdf

Actual vs expected

Measuring the embedded image in the resulting PDF (/Width and /Height of the image XObject):

Page size requested	Image pixels @300 dpi	Actual scan area
Custom 8.5 × 36 in (profile)	2550 × 3300	8.50 × 11.00 in ❌
Custom 8.5 × 36 in (--pagesize)	2550 × 3300	8.50 × 11.00 in ❌
Legal (<PageSize>Legal</PageSize>)	2550 × 4200	8.50 × 14.00 in ✅

Expected: the requested 8.5 × 36 in area is scanned; or, if the device cannot support it,
the scan is clamped to the device maximum and the user is told.

Actual: silently scanned at Letter.

Note the result is exactly Letter, not the device's declared maximum. The vendor driver's
ScannerProperties.plist declares ICAP_PHYSICALHEIGHT = 7020 (÷600 dpi = 11.7 in) for the
feeder unit, so a clamp to the device maximum would have produced 11.7 in. Getting exactly
11.00 in suggests NAPS2 is falling back to a Letter default rather than clamping — i.e. the
custom size is dropped before it reaches ImageCaptureCore.

Suggested fix

In NAPS2.Scan.Internal.Apple.AppleScanDriver, custom PageSize values appear not to be
translated into the ICScannerFunctionalUnit scan area. Even if the size cannot be honored,
surfacing a warning would prevent silent data loss — a truncated scan that reports success is
worse than a failed one, since the user only finds out when they look at the file later.

---

[cyanfish]

• Does it work with other custom page sizes? e.g. 8.5in x 10in
• What's the output of cat ~/.config/naps2/profiles.xml | grep 'ScanArea'? (will show reported max size)

[rqahmad]

for context my use case started with a longer receipt about 12-13 inches and kept getting cut off.

Does it work with other custom page sizes? e.g. 8.5in x 10in

No — custom sizes are ignored in both directions, while every enumerated
size is honored exactly:

--pagesize	image px @300dpi	actual	maps to DocumentType
a4	2480 x 3508	8.27 x 11.69	A4 ✅ exact
legal	2550 x 4200	8.50 x 14.00	USLegal ✅ exact
8.5x10in	2550 x 3300	8.50 x 11.00	Default ❌ Letter
8.5x36in	2550 x 3300	8.50 x 11.00	Default ❌ Letter

The correlation is exact: sizes mapping to a real ICScannerDocumentType
come back correct; sizes mapping to ICScannerDocumentType.Default come
back Letter, whether the request is larger or smaller.

This rules out the Math.Min clamp against PhysicalSize in SetScanArea:
8.5x10 is under any plausible max, and A4's 11.69" height exceeds Letter's
11", so PhysicalSize is not the limiting factor.

That points at:

feederUnit.DocumentType = GetDocumentTypeFromPageSize(_options.PageSize);

GetDocumentTypeFromPageSize returns Default for non-enumerated sizes, and
on this driver Default appears to mean US Letter and to override the
ScanArea set immediately afterwards. Worth testing whether skipping the
DocumentType assignment entirely (leaving ScanArea to do the work) fixes
custom sizes — the code comment already notes it "should be redundant".

What's the output of cat ~/.config/naps2/profiles.xml | grep 'ScanArea'?

No match (exit 1). Caps have never been populated for this device:

<Caps xsi:nil="true" />

That's after scans via both the GUI and CLI across two profiles. Possibly
a separate issue, or related.

Scanner: Ambir ImageScan Pro 830ix (USB 0x20EC:0x830A), vendor ICA driver
"Ambir Scanner.app" 1.0.1.21, macOS 26.5.2 arm64, NAPS2 8.3.2. Hardware
rated 8.5 x 200in. Happy to test a patched build or run with debug logs.

[cyanfish]

Removing DocumentType will just make it so page size doesn't work at all, this issue is why it was added to begin with (#249).

It seems like ImageCaptureCore may not support custom scan areas for feeder scanners at all. (Try opening the builtin macOS Image Capture app and select a feeder.) You could try scanning a bigger fixed page size (e.g. A3) and crop it down later. I'll hide the Custom page size options for ICC feeders in the next version (b43aa68).