Compress on export: offer the setting that actually shrinks a scan

[JamesmarkeyUK]

A 45 MB scan compressed to 1.5 MB in Universal Compress but reported no savings in Universal PDF's Export dialog, which greyed the Compressed tab out entirely.

The engines are not the difference. Universal Compress's src/lib/compress/pdf.ts is a port of this repo's compressPdf, down to the raster presets (balanced 1.5×/0.7, maximum 1.0×/0.45) and the same pdf-lib / pdfjs-dist versions. The entry point was.

What was wrong

ExportModal called compressPdf with no quality argument, so it took the 'light' default — a lossless object-stream re-save. On a scan, whose bulk is image data, that is a few percent at best, so the tab it feeds had nothing to offer and disabled itself. Only the landing page's compress pill ever passed 'balanced'.

Changes

Export gets the quality control. The same Light / Balanced / Maximum choice the Compress dialogs have. 'light' stays the default there and only there: an export is an annotated — often signed — document, and rasterising it costs the text layer. That is a trade worth offering, not worth making on someone's behalf, and the dialog says so plainly when a rasterising level is picked. Compression is now its own pass, so changing the level re-compresses the annotated bytes instead of re-baking every annotation and re-rasterising every redaction to arrive at the identical input again.

The lossless yardstick is no longer always paid for. The never-return-a-bigger-file guarantee was measured by saving the whole source document a second time. On a 45 MB scan that is a second 45 MB buffer on top of the source, pdf.js's copy and the parsed document — the slowest step in the function, and one big files were dying on. It now runs only when the lossless pass could plausibly win: repacking removes structural slack, never image data, so a raster result under half the original is a landslide the yardstick cannot overturn. The guarantee itself is unchanged — a text-only PDF still comes back losslessly rather than as 860 KB of JPEG.

Progress reporting. compressPdf reported nothing at all, so a long rasterising run was indistinguishable from a hung dialog. It now takes an onProgress callback, threaded through the export dialog as a bar and through the landing page and both Compress dialogs as a percentage.

Verification

Driven in a real Chromium against the dev server, not only typechecked.

Engine, on an 8-page image-heavy fixture:

level	result
Light	16.72 MB → 16.72 MB (0.0% off)
Balanced	16.72 MB → 1.41 MB (91.6% off)
Maximum	16.72 MB → 0.29 MB (98.3% off)
Balanced, text-only fixture	falls back to lossless, no bloat

Progress fires per page, is monotonic, and reaches 1 on both the lossless and rasterising paths.

The Export dialog itself, driven through the UI: opens on Light; at Light the scan shows "no savings" with the Compressed tab disabled (the reported bug); switching to Balanced shows a progress bar and then −92% with the tab live; the text-layer warning is visible.

Unrelated, but worth knowing for anyone doing browser-level testing here: npm run dev throws into the ErrorBoundary without VITE_PLATFORM_SUPABASE_URL / VITE_PLATFORM_SUPABASE_ANON_KEY set. Pre-existing, and no env config is committed here.

---

Generated by Claude Code