Bug 461915

Summary: fop massively scales up some jpeg images in pdfs
Product: [Fedora] Fedora Reporter: Murray Cumming <murrayc>
Component: fopAssignee: Lillian Angel <langel>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: fitzsim
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-14 14:26:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Murray Cumming 2008-09-11 12:20:42 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:
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.

Comment 1 Lillian Angel 2008-09-18 16:41:17 UTC
Filed upstream
https://issues.apache.org/bugzilla/show_bug.cgi?id=45835

Comment 2 Lillian Angel 2008-09-18 17:44:20 UTC
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.

Comment 3 Murray Cumming 2008-09-18 19:37:21 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.

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.

Comment 4 Lillian Angel 2008-09-19 12:40:48 UTC
This was acknowledged as a bug in xmlgraphics-commons and fixed upstream.

Will be in the next release.

Comment 5 Bug Zapper 2009-06-10 02:41:33 UTC
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

Comment 6 Bug Zapper 2009-07-14 14:26:56 UTC
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.