The issue of red and blue switching, with transparency, is fixed. Any other colour switching is due to other issues, and should be put under a different jira, specific to that other cause.

The support_3876.pdf rendering blank issue turned out to be a regression from PDF-68. Patrick fixed it in PDF-129.

Although the logo at the top is still a different colour than what it is in Acrobat. Acrobat shows it as green and we show it as blue, both in the current code and in the code before this fix. So it doesn't look like it's due to this issue. Especially since it's green, not red, in Acrobat.

Investigation of the support_3876.pdf regression shows that it's due to resources being null, and there being no "Resources" in the entries dictionary, in org.icepdf.core.pobjects.fonts.nfont.NFontType3.getGlyph(int). This causes a NPE that stops the shapes from drawing, leaving the page mostly blank.

Fixed the image skewing issue with 057.PDF. The method that read the bytes, and converted them into packed integers, did not account for the underlying InputStream not giving all of the desired bytes at a time, which required adding a loop to ensure they're all gotten. Missing bytes caused a skewing effect.

\\iceads1\Public\ICEpdf Development\PDF Examples\SmokeTest\057.PDF
D:\ICEpdf\iceads1_Public_ICEpdf_Development\PDF Examples\SmokeTest\057.PDF

Subversion 20199
icepdf\core\src\org\icepdf\core\pobjects\Stream.java

Previous attempts to fix this had failed, because the approaches were similar in that they fed a byte[] -> DataBuffer -> WritableRaster -> BufferedImage, in such a way that the bytes were not being explicitly described as ARGB, RGB, BGR, or BGRA. Different JVMs, on different platforms, made different assumptions about the ordering.

While working on JBIG2 integration in PDF-9, optimising the code to not redundantly allocate memory, I recognised that the appoach used there, of creating the BufferedImage with an explicit type, of BufferedImage.TYPE_INT_ARGB, could be adapted here. In PDF-9, I took the pre-existing code, that created a BufferedImage (which internally allocates an int[] backed raster), and then explicitly allocates an int[], and replaces the internally created one with the explicitly created one. I then altered the code to not allocate an explicit int[], but simply access the internally created one, and fill it with the pixel data. So, the idea was to translate that technique over, but instead of using int[] and TYPE_INT_ARGB, use byte[] and TYPE_4BYTE_ABGR or TYPE_3BYTE_BGR. That way when not using alpha, we'd still only use 3 bytes per pixel, and only use 4 bytes per pixel when using alpha.

Unfortunately, that didn't fix anything. Instead of further investigation as to how to re-order the bytes, I decided to simply use the int[] and TYPE_INT_ARGB. Along with that, I could then replace the implicit access to the red green blue and alpha, via array indexes, with explicit access to each component. The drawback being that we always use 4 bytes per pixel, even without alpha.

One benefit to memory usage, of the new approach, over the old one, is that the old one used a byte[] output stream, which dynamically grew as it built up the byte[]. The negative side-effect of that was that it would typically over-grow. And trimming it down to size would require allocating an intermediary byte[] and copying between them. That could get costly. The new approach uses an exactly size int[] and fills it without any intermediary buffer, let alone a dynamically sized one.

Testing shows that the colours are now as they should be, both for alpha and non-alpha RGB images.

Subversion 20103
icepdf\core\src\org\icepdf\core\pobjects\Stream.java

Found another regression from ICEpdf 2.7, which should be investigated, in case it's because of this code change, but that I don't really think is because of this code change. With this PDF, the page used to fully show, with the image in the wrong colour, and now most of the page doesn't show up at all. What I'd hope to find is that this is some other regression, which when fixed, will allow the content to display, to find the image now using the correct colours.

\\iceads1\Public\ICEpdf Development\PDF Examples\Type3\support_3876.pdf
D:\ICEpdf\iceads1_Public_ICEpdf_Development\PDF Examples\Type3\support_3876.pdf
Matching images: 483
Image: <unreferenced> Inline: true Pages: 0
...

When searching, using the new tagging capability, for the tag "RasterFromBytes_DeviceRGB_8_alpha=true", to find the 8 bit RGB with alpha, there were 21 matching PDFs, with several of those being redundant matches. I opened every one, and examined every page, and either each image was now fixed, or it was already correct, and there was no visible change.

When searching for "RasterFromBytes_DeviceRGB_8_alpha=true" there were 183 matching PDFs. I opened many in the list, and found all were still the same correct colouring, until I found the following:

\\iceads1\Public\ICEpdf Development\PDF Examples\SmokeTest\057.PDF
D:\ICEpdf\iceads1_Public_ICEpdf_Development\PDF Examples\SmokeTest\057.PDF
Matching images: 2
Image: R[106,0] Inline: false Pages: 0
Image: R[7,0] Inline: false Pages: 1

I will investigate further, since I'm essentially comparing the HEAD of CVS to the TRUNK of SVN, so 2.7 vs 4.0, so the colour change may be unrelated to my change, and be indicative of some other regression, particularly since the change involves some banding, and not RGB -> BGR switching.

Support 6592 is actually a different issue, and is about CMYK JPEG images, while Support 7219 is an RGB image with transparency that gets the red and blue flipped.