Excellent, thank you! Here it is:
https://paste.debian.net/hidden/355d54e1/
This skips the endianness check for all images where img2pdf should not care.
ah then this is an IM7 issue because i tested the current git HEAD on Debian with IM6 and the tests work fine on aarch64, ppc64el as well as s390x.
can i prepare another patch for you which…
Oh dear...
Okay, but the commit I referenced above is sufficient to fix this issue right now, correct? Though it will break in the future once IM7 decides to write little-endian TIFF on all…
nice! fixed in 29921eeabde1a2f9eb31f1383e5a820d9772c333
please file issues for any other problem you find
thanks!
29921eeabd
the default PDF/A icc profile is /usr/share/color/icc/sRGB.icc, /usr/share/color/icc/OpenICC/sRGB.icc or /usr/share/color/icc/colord/sRGB.icc depending on which one exists
@phmccarty would this patch fix your problem:
diff --git a/src/img2pdf.py b/src/img2pdf.py
index 6c58ea5..54701c9 100755
--- a/src/img2pdf.py
+++ b/src/img2pdf.py
@@ -3766,6…
nice, thank you for that research!
Then I propose to check for the existance of profiles in the following order and use the first one that exists as the default:
- `/usr/share/color/icc/sRGB…
64d27f4a8b
src/img2pdf_test.py: allow Bilevel as well as Grayscale type for png_gray1_img (closes: #161)
The endianness problems also occurred on s380x (also big endian) and were fixed in 33139612f85d8e638b759603957ebf62cce46d80
Thank you for finding this! But this is the wrong fix. The file /usr/share/color/icc/colord/sRGB.icc also exists in Debian but is different from /usr/share/color/icc/sRGB.icc (they come from…
I think the test can just accept both values because the line below checks:
assert identify[0]["image"].get("depth") == 1
So even if we call this a Grayscale image, it will still be…
Ah yes, you do. You reported this as #161
I'm closing this one in favour of #161
@gms do you also see this issue on Fedora with imagemagick 7.1?