Hi, poppler is not prepared at all for 16 bits per component images,
everywhere it assumes a component of the color fits into a Guchar (8 bits).
You can see the consequences with the pdf present at
http://bugs.kde.org/show_bug.cgi?id=158165
I have attached a 5 line patch that "fools" poppler and makes it use the high
8 bits and discard the other 8.
This makes it "work" but it's obviously a workaround and not the real solution
and i have only this pdf using 16 bits per component and it's really a "test
document" not a real one.
So i'm hesitating if incorporating the patch (with comments explaining the
workaround) or not doing it.
Comments?
Albert
diff --git a/poppler/GfxState.cc b/poppler/GfxState.cc
index f2f914d..4e7c010 100644
--- a/poppler/GfxState.cc
+++ b/poppler/GfxState.cc
@@ -3347,6 +3347,7 @@ GfxImageColorMap::GfxImageColorMap(int bitsA, Object *decode,
// bits per component and color space
bits = bitsA;
maxPixel = (1 << bits) - 1;
+ if (maxPixel > 255) maxPixel = 255;
colorSpace = colorSpaceA;
// initialize
diff --git a/poppler/Stream.cc b/poppler/Stream.cc
index c253129..6b13549 100644
--- a/poppler/Stream.cc
+++ b/poppler/Stream.cc
@@ -428,6 +428,11 @@ Guchar *ImageStream::getLine() {
for (i = 0; i < nVals; ++i) {
imgLine[i] = str->getChar();
}
+ } else if (nBits == 16) {
+ for (i = 0; i < nVals; ++i) {
+ imgLine[i] = str->getChar();
+ str->getChar();
+ }
} else {
bitMask = (1 << nBits) - 1;
buf = 0;
_______________________________________________
poppler mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/poppler
