While generating output as image/tiff it is only possible to use PackBits compression. I would like to use TIFF CCITT T.4 compression for output images.
Created attachment 18866 [details] Java2DRenderer.getPageImage(): Extract code into a protected method. Java2DRenderer.getPageImage(): Extract code into a protected method to instantiate the BufferedImage that we paint on. Right now, it always allocates an 24 bit RGB image with an 8-bit alpha channel. In next patch: Override the new protected method described above to create the Buffered image depending on the configuration.
Created attachment 18867 [details] modifs:getBufferedImage+iterator.next+configure+stopRenderer The buffered image returned by getBufferedImage() is defined during configure(). In the configure method, file configuration compression is assigned to the new parameter attribute who has changed to ImageWriterParams. Substitution of Batik tiff encoder for an ImageWriter. LazyPageImagesIterator.next() returns a new RenderedImage depending on the writer configuration. After all this I could generate CCTITT T.4 TIFF output but when generating multi paged tiffs only the first page is in the output. Also, using this patch in a j2ee EJB environement with jboss, the renderer only works once, since then the ByteArrayOutputStream is ever empty.
Created attachment 18868 [details] Moved ImageWriter creation outside of the iteration. I've moved the creation of the image writer outside the page iteration. The result is functionally the same: rendering only works first time for the first page of the m-tiff.
Against what branch of FOP did you do the patch? I can't apply it and it's really weird because your patch tries to change the license header which has been done long ago. It's important to do an "svn up" before creating the patch. And you should make sure you're producing the patch from FOP Trunk. I'll try to port your changes manually from your patch. But if you can supply updated patches against the latest FOP Trunk that would help.
(In reply to comment #3) > I've moved the creation of the image writer outside the page iteration. > The result is functionally the same: rendering only works first time for the > first page of the m-tiff. Hmm, I didn't think of that early enough it seems. The ImageWriter package does currently not support writing images with multiple sub-images (like TIFF does). I wrote it originally for Batik which only produces single images. I'll see if I can extend ImageWriter this weekend. I've got some ideas.
I've extended the ImageWriter abstraction in XML Graphics Commons to support multi-page formats like TIFF. I've also already made the necessary changes in TIFFRenderer. I will commit those tomorrow morning when I've tested some more and updated xmlgraphics-commons-1.1-snapshot.jar http://svn.apache.org/viewvc?view=rev&rev=447153 http://svn.apache.org/viewvc?view=rev&rev=447150
Patch applied with modifications. Thanks Oliver! http://svn.apache.org/viewvc?view=rev&rev=447325 You'll see from the change that I've solved the multi-page problem with the ImageWriter. Please test and send feedback if it works for you, too. I'll write some docs about it in the meantime.
(In reply to comment #4) > Against what branch of FOP did you do the patch? I can't apply it and it's > really weird because your patch tries to change the license header which has > been done long ago. It's important to do an "svn up" before creating the patch. > And you should make sure you're producing the patch from FOP Trunk. > > I'll try to port your changes manually from your patch. But if you can supply > updated patches against the latest FOP Trunk that would help. Sorry, but I had a lot of problems with a proxy and couldn't do an update. I did a visual comparation to the source from web and it seemed to me that I had the same source, but it was old. sorry, today I've solved the problem but i see you did the update manually. Thanks!
(In reply to comment #7) You're wellcome! I've just tried your patch and it works ok for me after some tests. Thanks for your improvements, your help and for dedicating your time to this issue. I'll keep on testing tomorrow and I'll give more feedback.
(In reply to comment #9) Today I've been trying the patch with CCITT T.4, CCITT T.6 and PackBits. All has worked fine. I ran everything in a Windows XP PC with jdk 1.5.0_03 and jai tools installed on the jdk. There's a little quality difference between CCITT T.4 and PackBits that I think it's due to the inherent compression of each type, or maybe some antialiasing on PackBits. Anyway the difference of quality is widely compensed by the difference of weight 2592kB on PackBits vs 240kB on CCITT T.4 for the same rendered MTIFF. Apparently there's no significant difference between CCITT T.4 and CCITT T.6.
I also have tryed to put jai_core.jar, jai_imageio.jar and jai_codec.jar on the classpath of the aplication (not in the jdk) and the patch went fine. Today I finish my job in notariado.org so I wont be available on ohernandez@notariado.org. For further contact please e-mail me in tramuntanal@gmail.com. Special thanks to Jeremias, don't hesitate to contact me for any topic.
Thanks for the feedback. I think it was an important addition to FOP.
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed