Red Hat Bugzilla – Bug 461915
fop massively scales up some jpeg images in pdfs
Last modified: 2009-07-14 10:26:56 EDT
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.
Filed upstream https://issues.apache.org/bugzilla/show_bug.cgi?id=45835
Comment posted on https://issues.apache.org/bugzilla/show_bug.cgi?id=45835 ------- Comment #1 From Andreas L. Delmelle 2008-09-18 10:01:22 PST [reply] 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.
> 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. This .fo (and the image) is in that tarball. > 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. Thanks. I'll try that. But this is a small (smaller enough for the page) image that is being scaled up by a few hundred percent, so that only a small corner of it is visible. This can't be desired behavior, and it is odd that it happens only for some images.
This was acknowledged as a bug in xmlgraphics-commons and fixed upstream. Will be in the next release.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.