Description of problem: When using fop to create a PDF document from DocBook XML, some (but not most) JPEG images are scaled up instead of being shown at 100%. In this test case, this results in only a small part of the image being shown on the page. This image was created from a .png (which had transparency, I think, in case that is interesting), with imagemagick's convert command, and then scaled down with imagemagick's "mogrify --resize 450x450" command. It seems to be that resizing that made an image that causes problems for fop, though fop has no problem with other images that were processed in the same way. Other applications, such as eog, have no problem with this file. (I did the conversion to JPEG because of bug #461740, and I did the resizing because I see no other way to tell fop, or the DocBook XSL, to fit the images on the page without cropping.) Steps to Reproduce: 1. Unpack this tarball: http://www.murrayc.com/temp/docbook_fop_jpeg_test.tar.gz (I would attach it but that does not work in this bugzilla for tarballs.) 2. cd into the directory 3. Do: xsltproc -o flumotion.fo -xinclude --catalogs http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl flumotion.xml 4: Do: fop -fo flumotion.fo -pdf flumotion.pdf The tarballs contains the generated PDF so you can see the result without even doing that.
It's always helpful (or: more convenient for us) to simply attach the FO-result. From that, even when we don't have the images, most fop-devs can immediately see possible causes for your issue. I suggest you look at any content-height/content-width properties specified on the external-graphics. If they are set to 'scale-to-fit', then a smaller JPEG will always be blown up until it fits exactly in the viewport (determined by width/height specified on the fo:external-graphic) How to customize Docbook to make sure content-height/content-width are set to 'scale-down-to-fit' (XSL 1.1; should work with FOP Trunk, maybe not yet in 0.95), is something I personally cannot help you with, unfortunately. In your description, it seems like that is exactly what you need: if the image is larger, then shrink it, otherwise maintain its intrinsic dimensions. If you only need the larger images to be clipped, then setting overflow="hidden" on the external-graphic would be enough (no scaling needed). Can you let us know if this helped? Seems like it's not a bug, but simply compliant behavior.
Created attachment 22602 [details] fo-result
Created attachment 22603 [details] pdf created
I attached the fo-result. Is there a problem with it? thanks for the description. I will pass this on to the reporter.
Thanks for the attachments. This seems a bit weird indeed. With all values set to "auto", FOP has no reason to scale the image at all... Just confirmed with FOP Trunk on Mac. The JPEG reports a size of 198x450 pixels at 88,9 dots-per-inch in Preview. A quick debug session shows that XML Graphics' ImageInfo also reports this height/width in pixels, but... with an apparent resolution of 13.7795dpi (misread somehow?), which makes the image about 14.37in high (= 1034.578pt = (198px/13.7795dpi) * 72dpi). FOP itself is not at fault here... Seems like an issue in XMLGraphics Commons. Anyone?
This is indeed a problem in XML Graphics Commons but it was transported over from FOP when the image loading framework was extracted from the old image loading code in FOP. I already have a fix. Will commit shortly.
Looks like I introduced that bug back in 2005 when I added support for reading the resolution in a JPEG file: https://svn.apache.org/viewvc?view=rev&revision=198294 And then, this migrated over into the new image loading framework. But it is fixed now: http://svn.apache.org/viewvc?rev=696949&view=rev Thanks for the detailed error report!