Forrest
  1. Forrest
  2. FOR-413

PDF: rendering fails when graphics too big - workaround inside

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 0.6
    • Fix Version/s: None
    • Component/s: Plugin: output.pdf
    • Labels:
      None

      Description

      When "forresting" a document that has embedded images, the PDF rendering sometimes stops with this error message:

      BROKEN: org.apache.fop.apps.FOPException: No meaningful layout in block after many attempts. Infinite loop is assumed. Processing halted.

      I've found that this is caused by images that are too big to fit in the PDF page (took me some times :) )

      (Moved workaround from Description to Comment - see 2005-12-24)
      1. added-wide-PNG-to-howto.patch
        0.6 kB
        Johannes Schaefer
      2. ASF.LICENSE.NOT.GRANTED--murks.fo
        2 kB
        Johannes Schaefer
      3. ASF.LICENSE.NOT.GRANTED--murks.fo
        2 kB
        Johannes Schaefer
      4. ASF.LICENSE.NOT.GRANTED--murks.zip
        67 kB
        Johannes Schaefer
      5. FOP-Test.zip
        503 kB
        Johannes Schaefer
      6. recovered-files.zip
        68 kB
        Johannes Schaefer
      7. remove-double-id.patch
        0.7 kB
        Johannes Schaefer

        Activity

        Show
        Johannes Schaefer added a comment - See also: http://mail-archives.eu.apache.org/mod_mbox/forrest-user/200502.mbox/%3c421A0687.6080908@uidesign.de%3e
        Hide
        Johannes Schaefer added a comment -
        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 ...
        Show
        Johannes Schaefer added a comment - 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 ...
        Hide
        Johannes Schaefer added a comment -
        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.
        --

        Show
        Johannes Schaefer added a comment - 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. --
        Hide
        Johannes Schaefer added a comment -
        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.
        Show
        Johannes Schaefer added a comment - 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.
        Hide
        Johannes Schaefer added a comment -
        Here are the images I used, see attachment murks.zip.
        Show
        Johannes Schaefer added a comment - Here are the images I used, see attachment murks.zip.
        Hide
        Johannes Schaefer added a comment -
        Just to clarify: padding-before="0pt" renders fine.
        Show
        Johannes Schaefer added a comment - Just to clarify: padding-before="0pt" renders fine.
        Hide
        Johannes Schaefer added a comment -
        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?!
        Show
        Johannes Schaefer added a comment - 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?!
        Hide
        David Crossley added a comment -
        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 -->
        Show
        David Crossley added a comment - 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 -->
        Hide
        Greg Jenci added a comment -
        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.
        Show
        Greg Jenci added a comment - 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.
        Hide
        Johannes Schaefer added a comment -
        Recovered the files murks.fo and murks.zip from my hard drive.
        Show
        Johannes Schaefer added a comment - Recovered the files murks.fo and murks.zip from my hard drive.
        Hide
        Johannes Schaefer added a comment -
        Test project for FOP update.

        Ferdinand, feel free to assign this bug to you ;-)
        Show
        Johannes Schaefer added a comment - Test project for FOP update. Ferdinand, feel free to assign this bug to you ;-)
        Hide
        Ferdinand Soethe added a comment -
        I'm plannung to fix this problem by updating FOP to the current release and adjusting FOP-stylesheets until Feb 2008
        Show
        Ferdinand Soethe added a comment - I'm plannung to fix this problem by updating FOP to the current release and adjusting FOP-stylesheets until Feb 2008
        Hide
        Johannes Schaefer added a comment -
        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).
        Show
        Johannes Schaefer added a comment - 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).
        Hide
        Johannes Schaefer added a comment -
        Patch to remove the double id(s) in index.html
        If present wholesite.(html|pdf) won't be generated.
        Show
        Johannes Schaefer added a comment - Patch to remove the double id(s) in index.html If present wholesite.(html|pdf) won't be generated.
        Hide
        Johannes Schaefer added a comment -
        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.
        Show
        Johannes Schaefer added a comment - 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.
        Hide
        Ferdinand Soethe added a comment -
        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.
        Show
        Ferdinand Soethe added a comment - 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.
        Hide
        Ferdinand Soethe added a comment -
        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.
        Show
        Ferdinand Soethe added a comment - 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.
        Hide
        David Crossley added a comment -
        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.
        Show
        David Crossley added a comment - 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.
        Hide
        David Crossley added a comment -
        I changed the linkmap-to-document.xsl stylesheet to address the "link" element described above at "30/Jan/08".
        Show
        David Crossley added a comment - I changed the linkmap-to-document.xsl stylesheet to address the "link" element described above at "30/Jan/08".

          People

          • Assignee:
            Ferdinand Soethe
            Reporter:
            Olivier Jacques
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development