|
Image width seems not to be a problem, screenshots with 1024x768 are included correctly although they're too high. It seems that FOP (?) scales them down because of width. High but narrow images cause problems. Seems like FOP cannot handle these ...
I think I circled it, see attachment. See detailed FOP output below.
The surprising thing is that everything works fine, i.e. the page renders with FOP, if there is neither padding-before nor padding-after set in this line: <fo:block padding-before="18pt"> With a wide instead of a high image the page renders fine, too. Is anybody in touch with FOP to check if this is a bug in FOP? FOP output (note: jimi-1.0.jar must be present): -- fop-0.20.5>fop murks.fo murks.pdf [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] FOP 0.20.5 [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] building formatting object tree [INFO] setting up fonts [INFO] [1] [INFO] JAI support was not installed (read: not present at build time). Trying to use Jimi instead [INFO] [2] [INFO] [3] [INFO] [4] [INFO] [5] and so on ........... ad infinitum. -- OK, the last one works since it contains a *wide* image. Sorry.
Here's the one that does break (high-image.gif). Note: Now I put in the same image as GIF and the behaviour is the same, so jimi is not needed. Here are the images I used, see attachment murks.zip.
Just to clarify: padding-before="0pt" renders fine.
See on the FOP mailing-list:
http://marc.theaimsgroup.com/?l=fop-user&w=2&r=1&s=infinite+loop&q=b most notably http://marc.theaimsgroup.com/?l=fop-user&m=107875799629370&w=2 These are the FOP bugs for "infinite loop" http://makeashorterlink.com/?D28F3288A Nothing seems to really fit, but maybe the murks.fo helps fixing anyway?! I temporary "solved" it by modifying the document2fo.xsl. When I specify the "width" or "height" attribute to the img, then the value is taken and divided by 2. WARNING: the value has to be an integer and a "px" (pixels) size.
We should find a way to reduce the size automatically. $ diff -bruN document2fo.xsl~ document2fo.xsl --- document2fo.xsl~ 2004-12-09 17:51:42.486185200 +0100 +++ document2fo.xsl 2004-12-09 22:03:32.465852800 +0100 @@ -755,10 +755,14 @@ </xsl:variable> <fo:external-graphic src="{$imgpath}"> <xsl:if test="@height"> - <xsl:attribute name="height"><xsl:value-of select="@height"/></xsl:attribute> + <xsl:variable name="reducedheight" + select="number(@height)" /> + <xsl:attribute name="height"><xsl:value-of select="concat(number($reducedheight) div 2,'px')"/></xsl:attribute> </xsl:if> <xsl:if test="@width"> - <xsl:attribute name="width"><xsl:value-of select="@width"/></xsl:attribute> + <xsl:variable name="reducedwidth" + select="number(@width)" /> + <xsl:attribute name="width"><xsl:value-of select="concat(number($reducedwidth) div 2,'px')"/></xsl:attribute> </xsl:if> </fo:external-graphic> <!-- alt text --> In my case, if the image is under 540px, Forrest doesn't seem to care. However, above the 540px mark, the image width to height ratio must be greater than 540:451. For example, one of my images was 1409px tall and originally 1043px wide, which caused the ugly error. However, once I apply the minimum 540:451 ratio and increase the width to 1175px, everything processes fine.
Recovered the files murks.fo and murks.zip from my hard drive.
Test project for FOP update.
Ferdinand, feel free to assign this bug to you ;-) I'm plannung to fix this problem by updating FOP to the current release and adjusting FOP-stylesheets until Feb 2008
Added an additional image to howto-docbook.xml to illustrate image scaling with "old" FOP: The wide image is scaled down to fit into the table cell (page).
Patch to remove the double id(s) in index.html
If present wholesite.(html|pdf) won't be generated. To generate wholesite.pdf one need to remove/comment this line
<linkmap label="Documentation ToC" href="linkmap.html" description="Table of Contents for this example site"/> Don't know why this happens. Still in wholesite.pdf the scaling (% and absolute) of images does not work although it works in the single PDFs, see sections 2.8 and 2.9. The problem seems to be within linkmap since calling linkmap.pdf creates the same error.
Calling linkmap.pdf with Forrest 0.8 I get a "The requested resource "/linkmap.pdf" could not be found"-error, so the problem doesn't see to be new. Will try to figure out why anyhow. looking at linkmap.xml I see a document that claims to be
DTD Documentation V1.2//EN but uses a-elements for linking which are not legal in this grammar. Probably - I didn't find my way all through the sitemap - this misrepresentation of the document type prevents it from being tranformed to proper document v1.3 which is expected when transforming to fop. Rather than hacking fop to support a elements I'd suggest to fix the linkmap-pileline to produce valid xml. Both linkmap.pdf and wholesite.pdf work fine in current 0.9-dev trunk. Don't forget that there was a fix recently in trunk for "wholesite". These issues should be discussed separately to this "graphics too big" issue.
I changed the linkmap-to-document.xsl stylesheet to address the "link" element described above at "30/Jan/08".
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Major
PDF: rendering fails when graphics too big - workaround inside
http://mail-archives.eu.apache.org/mod_mbox/forrest-user/200502.mbox/%3c421A0687.6080908@uidesign.de%3e