mirror of
https://github.com/storytold/pdfcraft.git
synced 2026-10-31 15:49:36 +00:00
Grzegorz MartensandClaude Opus 5.5
aaa3d815c1
decode_ccitt reads byte-aligned Group 3 whose data has end-of-line codes but none before the first row (not as T.4 sends them) on bytes. At /K 0 with the fill ending each code on a byte, about one small picture in five is then read as other rows; at fax width almost none are, as such pages come out short and are refused. Export already said so. The optimizer, when it resamples such an image or stores it again as Group 4 from behind another filter, and redaction, when it clears pixels in one, write those rows back, and nothing said that. Black-box, PdfCraft's renderer draws such an image exactly as decode_ccitt reads it (all 42 misread of 200 seeded pictures, behind ASCII85Decode too), so the written image is what PdfCraft showed before. Refusing such data instead (a code after nearly every row but none first) would also refuse some ordinary Modified Huffman images, whose rows can meet 11 zeros by chance (0.5 to 5% of small ones in a black-box probe), so the limit is stated rather than guarded: in decode_ccitt's doc, the filters, optimize and redact READMEs, and the core.image-filters and mono-compression notes. The optimize README's and the mono-compression note's "not yet: Group 3 to Group 4 without resampling" now say a lone Group 3 image: one behind another filter is stored again as Group 4. Also from the review: docs/roadmap.md keeps #4335's status line under this PR's, rather than replacing it; the filters README's tests and the core.image-filters evidence name the Group 3 layout test; the filters crate's description names Group 3 and 4 decoding. From reviews with the pdfcraft-review skill. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01P6yUtvWGPsJpMLyh6pxSXG