https://issues.apache.org/bugzilla/show_bug.cgi?id=45835
Andreas L. Delmelle <[EMAIL PROTECTED]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #1 from Andreas L. Delmelle <[EMAIL PROTECTED]> 2008-09-18
10:01:22 PST ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
