similarity index 82%
rename from meta-python/recipes-devtools/python/python3-pikepdf_10.10.0.bb
rename to meta-python/recipes-devtools/python/python3-pikepdf_10.11.0.bb
@@ -1,9 +1,10 @@
SUMMARY = "Read and write PDFs with Python, powered by qpdf"
+DESCRIPTION = "Read, write, repair, and transform PDFs in Python, powered by qpdf"
HOMEPAGE = "https://github.com/pikepdf/pikepdf"
LICENSE = "MPL-2.0"
LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=9741c346eef56131163e13b9db1241b3"
-SRC_URI[sha256sum] = "9f134806b2fe608ccb21379a664ddcefeac3f6944100d343b350299d3c69754e"
+SRC_URI[sha256sum] = "4bebc59ac74411064e7c97a4036174023e22ccbecd22b78750ab76551eb38988"
SRC_URI += "file://0001-pyproject.toml-Do-not-strip.patch"
Upgrade to release 10.11.0: - Extended PDF outline (bookmark) support to cover more of the spec - Fixed 1-bit /Indexed images losing their palette when extracted. {meth}pikepdf.PdfImage.as_pil_image and {meth}pikepdf.PdfImage.extract_to previously ignored the palette of a 1-bit indexed image over a /DeviceCMYK base (returning a bilevel grayscale image) and of a single-colour palette (hival 0). Both now decode correctly, matching the existing behavior for 2/4/8-bit indexed images. - A 1-bit /Indexed image whose base colour space is unsupported (for example /DeviceN or /Separation) now raises NotImplementedError instead of silently returning an unpalettized image, matching the 2/4/8-bit path. - Image extraction now verifies that the image stream holds enough\ data for the declared /Width and /Height before allocating, raising {exc}~pikepdf.exceptions.ImageDecompressionError when it does not. This closes the remaining decompression-bomb gaps left by the {attr}pikepdf.PdfImage.MAX_IMAGE_PIXELS limit added in v10.10.0: that limit bounds the declared size, but said nothing about whether the declared size was consistent with the data present, so a 4-bit image declaring 12000x12000 -- well under the default 500M pixel budget -- still allocated ~300 MB from a single byte of stream data, and setting the limit to None restored the unbounded case entirely. The 2-bit and 4-bit unpack path and the 1-bit path (where Pillow allocates a byte per pixel before it notices the data is short) are both covered; 8-bit and 16-bit images already failed cleanly. The check applies regardless of MAX_IMAGE_PIXELS. - The 2-bit and 4-bit unpack buffer is no longer over-allocated by a factor of the packing ratio, reducing peak memory for those images by 4x and 2x respectively. - Extracting a 1-, 2-, or 4-bit image whose stream is shorter than its declared dimensions require now raises - {exc}~pikepdf.exceptions.ImageDecompressionError rather than returning a partially decoded image with a black tail. This matches what 8-bit and 16-bit images have always done for the same defect. - An image with a non-positive /Width or /Height raises {exc}~pikepdf.exceptions.InvalidPdfImageError instead of failing further down with an obscure error from Pillow. Signed-off-by: Leon Anavi <leon.anavi@konsulko.com> --- .../{python3-pikepdf_10.10.0.bb => python3-pikepdf_10.11.0.bb} | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) rename meta-python/recipes-devtools/python/{python3-pikepdf_10.10.0.bb => python3-pikepdf_10.11.0.bb} (82%)