Bug 45835 - fop massively scales up some jpeg images in pdfs
Summary: fop massively scales up some jpeg images in pdfs
Alias: None
Product: XMLGraphicsCommons - Now in Jira
Classification: Unclassified
Component: image codecs (show other bugs)
Version: 1.3.1
Hardware: All All
: P2 normal (vote)
Target Milestone: --
Assignee: XML Graphics Project Mailing List
URL: https://bugzilla.redhat.com/show_bug....
Depends on:
Reported: 2008-09-18 09:39 UTC by Lillian Angel
Modified: 2008-09-19 00:17 UTC (History)
1 user (show)

fo-result (87.76 KB, application/octet-stream)
2008-09-18 10:38 UTC, Lillian Angel
pdf created (25.30 KB, application/pdf)
2008-09-18 10:38 UTC, Lillian Angel

Note You need to log in before you can comment on or make changes to this bug.
Description Lillian Angel 2008-09-18 09:39:21 UTC
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:
(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.
Comment 1 Andreas L. Delmelle 2008-09-18 10:01:22 UTC
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.
Comment 2 Lillian Angel 2008-09-18 10:38:04 UTC
Created attachment 22602 [details]
Comment 3 Lillian Angel 2008-09-18 10:38:15 UTC
Created attachment 22603 [details]
pdf created
Comment 4 Lillian Angel 2008-09-18 10:41:15 UTC
I attached the fo-result. Is there a problem with it?

thanks for the description. I will pass this on to the reporter.
Comment 5 Andreas L. Delmelle 2008-09-18 13:44:35 UTC
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?
Comment 6 Jeremias Maerki 2008-09-19 00:09:20 UTC
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.
Comment 7 Jeremias Maerki 2008-09-19 00:17:01 UTC
Looks like I introduced that bug back in 2005 when I added support for reading the resolution in a JPEG file:

And then, this migrated over into the new image loading framework. But it is fixed now:

Thanks for the detailed error report!