mirror of
https://github.com/storytold/pdfcraft.git
synced 2026-11-03 06:51:50 -06:00
Grzegorz MartensandClaude Opus 5.5
ea6c329731
decode_jbig2 sits next to decode_ccitt, through hayro-jbig2 as Export ▸ Images used it, and shares CCITT's row sink. The JBIG2 page has to be the image's size: PdfCraft's renderer draws the whole page into the image (black box: a 4-row page behind /Height 2 fills the image box with all four rows), so the rows of a taller page aren't the image's. The decoder decodes a page whole, so the page is checked before it is decoded: that size, within the caller's bound as rows of one bit, and at most 2^28 pixels (MAX_JBIG2_PIXELS; the decoder keeps a bit a pixel, about 34 MB there). Document::decoded_image_within decodes a JBIG2 image as it does a fax image: the filters before it undone first, then the decoder with the /JBIG2Globals of the image's own /DecodeParms entry (/Crypt counts in the position; fax_params and the globals now share last_filter_parms). Globals have a limit of their own, MAX_JBIG2_GLOBALS (32 MiB, moved from Export), and globals that can't be read are an error rather than ignored. Export ▸ Images reads JBIG2 through it, so its own decoder, row sink and DecodeParms reader go, and hayro-jbig2 leaves pdfcraft-create. JBIG2 behind another filter now exports, and so copies (Copy Image uses the same function); a page taller than the image, which Export cut to the image's rows, now skips the image, as one of another width did. doc_export_all_images' description no longer lists JBIG2 inside other filters as skipped. The optimizer's monochrome step read images through decoded_image_within and relied on JBIG2 failing there: it now leaves JBIG2 images alone explicitly, as before (a resampled one would come out Flate under Retain), and the README and parity note list them as not yet handled. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>