Re: PNG transparency renders as black - urgent
...just to keep the track - I applied your patch as you posted it, worked nice for all my PNGs (but I didn't explicitly tested various png types); Thanks for the help! Martin Jeremias Maerki wrote: Actually, this is so simple, I've created a patch. I'm hesitant to apply it without much testing with various PNGs for which I have no time right now. But maybe one of you can take a look. If it's good JAIImage and JimiImage could be similarly patched. On 19.12.2006 23:01:36 Jeremias Maerki wrote: It turns out the following revision is responsible for the regression: http://svn.apache.org/viewvc?rev=424349view=rev Putting the Commons codec before the ImageIO variant in ImageFactory is a quick fix for this. I originally switched because of speed reasons but obviously I didn't test PNGs with alpha channel. The reason why Martin's PNG doesn't work with the ImageIOImage class is the lack of support for java.awt.Transparency.TRANSLUCENT. If it were a BITMASK it would work. The same problem exists for JAIImage and JimiImage, BTW. Again, this is something a complete redesign of the image package would have addressed. It's on my higher priority list but I still haven't got to it, yet. If someone wants to try to implement that little code that is missing as a temporary fix, please do. It shouldn't be difficult. You can maybe use XmlGraphicsCommonsImage for hints. On 19.12.2006 20:30:35 Andreas L Delmelle wrote: On Dec 19, 2006, at 19:56, Peter wrote: When working on the patch I certainly can not remember coming anywhere close to code that could have an influence on how png's get into the pdf. I was also a bit puzzled, since in the patch there are no explicit references to anything png-related (IIC, png-related stuff is already put in Commons for that matter, so it couldn't have been touched directly by the patch) OTOH, this was the only significant change to the codebase between 13.11 and now, so one can reasonably assume that the cause is in there somewhere... I'd expect something which has an impact on the interaction with the commons-lib? Cheers, Andreas Jeremias Maerki Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PNG transparency renders as black - urgent
I would like to know what to do for the release: 1. Leave as is, a known problem. 2. Do the quick fix as jeremias suggests: putting the Commons codec before the ImageIO variant in ImageFactory. 3. Test Jeremias' patch and apply it. We can do the fix in the release branch (to be created) only, in the interest of an errorless release. Simon On Tue, Dec 19, 2006 at 11:14:13PM +0100, Jeremias Maerki wrote: Actually, this is so simple, I've created a patch. I'm hesitant to apply it without much testing with various PNGs for which I have no time right now. But maybe one of you can take a look. If it's good JAIImage and JimiImage could be similarly patched. On 19.12.2006 23:01:36 Jeremias Maerki wrote: It turns out the following revision is responsible for the regression: http://svn.apache.org/viewvc?rev=424349view=rev Putting the Commons codec before the ImageIO variant in ImageFactory is a quick fix for this. I originally switched because of speed reasons but obviously I didn't test PNGs with alpha channel. The reason why Martin's PNG doesn't work with the ImageIOImage class is the lack of support for java.awt.Transparency.TRANSLUCENT. If it were a BITMASK it would work. The same problem exists for JAIImage and JimiImage, BTW. Again, this is something a complete redesign of the image package would have addressed. It's on my higher priority list but I still haven't got to it, yet. If someone wants to try to implement that little code that is missing as a temporary fix, please do. It shouldn't be difficult. You can maybe use XmlGraphicsCommonsImage for hints. -- Simon Pepping home page: http://www.leverkruid.eu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PNG transparency renders as black - urgent
Hi, I quickly tried your files after processing them into png8 and png 24 with Adobe Illustrator: the transparency is working with png 8, not with PNG24 (I'm using FOP 0.20.5). I didn't investigate further. I hope this helps. I join the files. Nadege -Message d'origine- De : Martin Zak [mailto:[EMAIL PROTECTED] Envoyé : mardi 19 décembre 2006 17:38 À : fop-users@xmlgraphics.apache.org Objet : PNG transparency renders as black - urgent Hi all, really I'm the only one who came to this issue?? Any feedback is welcomed... Thanks Martin Original Message Subject:PNG transparency renders as black Date: Thu, 07 Dec 2006 16:09:18 +0100 From: Martin Zak [EMAIL PROTECTED] Reply-To: fop-users@xmlgraphics.apache.org, [EMAIL PROTECTED] Organization: Ginger Alliance To: fop-users@xmlgraphics.apache.org Hi all, I had to go for a trunk version of FOP due to some fixes available in this version. Unfortunately it seems I came to the bug which was introduced in some of the new versions. When including PNG image containing transparent areas (using fo:external-graphic), the image is corrupted. The transparent area is rendered in black and also the image itself seems to doubled while shifted down (see the sample). I used the same image with the FOP binary from November 13th, and the result was ok. Also the size of the resulting pdf differs a lot (141kB with old/correct version against 37kB with new/wrong). (BTW how do I find the build version when fop says FOP Version svn-trunk ?? Where to look for the version info?) Any idea what could change? (we use fop in production and got to troubles after the update :| ) Files: png_transparency.fo test.png png_transparency_good.pdf [pdf generated with fop trunk of November 13th] png_transparency_wrong.pdf[pdf generated with fop trunk of today (December 7th)] Cheers Martin MartinZak8.png Description: MartinZak8.png MartinZak24.png Description: MartinZak24.png - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PNG transparency renders as black - urgent
...just to point out that I used the same image with the FOP binary from November 13th, and the result was *ok*. What changed between these versions??? Also I tried to convert to indexed colors with transparency (in photoshop) and it also works. But full PNG (RGB, 24-bit) with transparency doesn't. We updated fop (for various reasons) on the client server and got to this bad situation :(( it's urgent otherwise they will chop my head off :| cheers Martin Martin Zak wrote: Hi all, really I'm the only one who came to this issue?? Any feedback is welcomed... Thanks Martin Original Message Subject: PNG transparency renders as black Date: Thu, 07 Dec 2006 16:09:18 +0100 From: Martin Zak [EMAIL PROTECTED] Reply-To: fop-users@xmlgraphics.apache.org, [EMAIL PROTECTED] Organization: Ginger Alliance To: fop-users@xmlgraphics.apache.org Hi all, I had to go for a trunk version of FOP due to some fixes available in this version. Unfortunately it seems I came to the bug which was introduced in some of the new versions. When including PNG image containing transparent areas (using fo:external-graphic), the image is corrupted. The transparent area is rendered in black and also the image itself seems to doubled while shifted down (see the sample). I used the same image with the FOP binary from November 13th, and the result was ok. Also the size of the resulting pdf differs a lot (141kB with old/correct version against 37kB with new/wrong). (BTW how do I find the build version when fop says FOP Version svn-trunk ?? Where to look for the version info?) Any idea what could change? (we use fop in production and got to troubles after the update :| ) Files: png_transparency.fo test.png png_transparency_good.pdf [pdf generated with fop trunk of November 13th] png_transparency_wrong.pdf[pdf generated with fop trunk of today (December 7th)] Cheers Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PNG transparency renders as black - urgent
On Dec 19, 2006, at 19:04, Martin Zak wrote: ...just to point out that I used the same image with the FOP binary from November 13th, and the result was *ok*. What changed between these versions??? AFAICT from the fop-commits archive: exactly on that day, support was added for rgb-icc() and a proprietary cmyk() function... As to how this influences the rendering of PNGs, I'm unfortunately at a loss :/ Hopefully Jeremias (who applied the patch) or Peter (the patch's author) have an idea on this, and chime in later on. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PNG transparency renders as black - urgent
When working on the patch I certainly can not remember coming anywhere close to code that could have an influence on how png's get into the pdf. I will take a look at it (unless Jermias beats me at it) this week (hopefully tomorrow) Peter -Original Message- From: Andreas L Delmelle [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 19, 2006 7:16 PM To: fop-users@xmlgraphics.apache.org Subject: Re: PNG transparency renders as black - urgent On Dec 19, 2006, at 19:04, Martin Zak wrote: ...just to point out that I used the same image with the FOP binary from November 13th, and the result was *ok*. What changed between these versions??? AFAICT from the fop-commits archive: exactly on that day, support was added for rgb-icc() and a proprietary cmyk() function... As to how this influences the rendering of PNGs, I'm unfortunately at a loss :/ Hopefully Jeremias (who applied the patch) or Peter (the patch's author) have an idea on this, and chime in later on. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PNG transparency renders as black - urgent
On Dec 19, 2006, at 19:56, Peter wrote: When working on the patch I certainly can not remember coming anywhere close to code that could have an influence on how png's get into the pdf. I was also a bit puzzled, since in the patch there are no explicit references to anything png-related (IIC, png-related stuff is already put in Commons for that matter, so it couldn't have been touched directly by the patch) OTOH, this was the only significant change to the codebase between 13.11 and now, so one can reasonably assume that the cause is in there somewhere... I'd expect something which has an impact on the interaction with the commons-lib? Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PNG transparency renders as black - urgent
It turns out the following revision is responsible for the regression: http://svn.apache.org/viewvc?rev=424349view=rev Putting the Commons codec before the ImageIO variant in ImageFactory is a quick fix for this. I originally switched because of speed reasons but obviously I didn't test PNGs with alpha channel. The reason why Martin's PNG doesn't work with the ImageIOImage class is the lack of support for java.awt.Transparency.TRANSLUCENT. If it were a BITMASK it would work. The same problem exists for JAIImage and JimiImage, BTW. Again, this is something a complete redesign of the image package would have addressed. It's on my higher priority list but I still haven't got to it, yet. If someone wants to try to implement that little code that is missing as a temporary fix, please do. It shouldn't be difficult. You can maybe use XmlGraphicsCommonsImage for hints. On 19.12.2006 20:30:35 Andreas L Delmelle wrote: On Dec 19, 2006, at 19:56, Peter wrote: When working on the patch I certainly can not remember coming anywhere close to code that could have an influence on how png's get into the pdf. I was also a bit puzzled, since in the patch there are no explicit references to anything png-related (IIC, png-related stuff is already put in Commons for that matter, so it couldn't have been touched directly by the patch) OTOH, this was the only significant change to the codebase between 13.11 and now, so one can reasonably assume that the cause is in there somewhere... I'd expect something which has an impact on the interaction with the commons-lib? Cheers, Andreas Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PNG transparency renders as black - urgent
Actually, this is so simple, I've created a patch. I'm hesitant to apply it without much testing with various PNGs for which I have no time right now. But maybe one of you can take a look. If it's good JAIImage and JimiImage could be similarly patched. On 19.12.2006 23:01:36 Jeremias Maerki wrote: It turns out the following revision is responsible for the regression: http://svn.apache.org/viewvc?rev=424349view=rev Putting the Commons codec before the ImageIO variant in ImageFactory is a quick fix for this. I originally switched because of speed reasons but obviously I didn't test PNGs with alpha channel. The reason why Martin's PNG doesn't work with the ImageIOImage class is the lack of support for java.awt.Transparency.TRANSLUCENT. If it were a BITMASK it would work. The same problem exists for JAIImage and JimiImage, BTW. Again, this is something a complete redesign of the image package would have addressed. It's on my higher priority list but I still haven't got to it, yet. If someone wants to try to implement that little code that is missing as a temporary fix, please do. It shouldn't be difficult. You can maybe use XmlGraphicsCommonsImage for hints. On 19.12.2006 20:30:35 Andreas L Delmelle wrote: On Dec 19, 2006, at 19:56, Peter wrote: When working on the patch I certainly can not remember coming anywhere close to code that could have an influence on how png's get into the pdf. I was also a bit puzzled, since in the patch there are no explicit references to anything png-related (IIC, png-related stuff is already put in Commons for that matter, so it couldn't have been touched directly by the patch) OTOH, this was the only significant change to the codebase between 13.11 and now, so one can reasonably assume that the cause is in there somewhere... I'd expect something which has an impact on the interaction with the commons-lib? Cheers, Andreas Jeremias Maerki Jeremias Maerki imageIOImageTransparencyPatch.txt Description: Binary data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
