ZacharyZhang-NYandClaude Opus 5.5
13546ea899
Windows prints through the system dialog at the document's paper; Linux through the desktop portal, the dialog's choices laid out by Ely. Round 3 findings fixed without a further review, as the rules say. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
3.4 KiB
FAIL
-
crates/ely-platform/src/print/linux.rs:52 — The PreparePrint response is reduced to its token; returned page ranges and scaling are discarded before sending the original PDF. With a three-page document, selecting only page 2 and 50% scaling still prints all three pages at their original size through the GTK portal backend. The application probe confirmed unchanged bytes were sent; an independent GTK 3.24.52 Print to File job confirmed the resulting output was byte-for-byte identical to the three-page input (
.work/r76-review-r1/linux-probe.log,gtk-backend-result.log). Follow the portal's prepare/format/print contract and apply the returned page selection and layout settings exactly once; test the resulting pages and geometry. See the Print portal contract. -
crates/ely-platform/src/print/win/printer.rs:60 — Driver normalization silently replaces unsupported custom paper, and the accepted dimensions are never checked. Printing a 1000×600-point PDF through Microsoft Print to PDF produced an 842×595-point page, cutting off the right-hand content, while print_pdf returned true. The only indication was a log warning (
.work/r76-review-r1/windows-probe.log). Correct the custom-paper configuration and validate the accepted paper dimensions; if the printer cannot honor them, surface that failure instead of reporting a successful, cropped print. Add a custom-paper output regression. -
crates/ely-platform/src/print/linux.rs:127 — Box coordinates are treated as points without applying the page's /UserUnit. A valid PDF with MediaBox [0 0 421 297.5] and UserUnit 2 is A4 landscape (842×595 points), but the public print path sent custom_105x149mm to the portal. The added probe failed the A4 assertion (
.work/r76-review-r1/linux-probe.log); the existing MuPDF UserUnit test passed independently. Multiply box dimensions by the page's UserUnit before choosing paper and applying rotation, and cover this in the print tests so printed paper agrees with the preview. -
crates/ely-platform/src/print/win.rs:160 — Every job returned by the system dialog has output: None, discarding PD_PRINTTOFILE and the DEVNAMES output field. When the user selects an ordinary printer and enables Windows 11's “Print to file” switch, StartDocW receives a null output destination and submits to that printer instead of requesting an output filename. The current integration test bypasses this branch using ELY_PRINT_TO. Preserve the dialog's file-output selection and pass FILE: to DOCINFO.lpszOutput as required by the PrintDlgEx contract; cover the dialog-result-to-job mapping.
-
crates/ely-platform/src/print/linux.rs:47 — PreparePrint omits supported_output_file_formats, advertising support for PDF, PostScript and SVG even though this path always supplies PDF bytes. On the GTK portal, choosing PostScript in Print to File therefore writes a PDF under the requested .ps filename. The real GTK backend probe reproduced this: the .ps file began with %PDF-1.4 and was identical to the PDF input (
.work/r76-review-r1/gtk-backend-result.log). Advertise only pdf in the portal options and verify that restriction in the portal test; the portal contract explicitly treats an omitted format list as support for all formats.