images not reliably reproduced in PDFs

• Key: FOR-635
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Unassigned
• Reporter: David Crossley
• Component/s: Documentation and website
• Affects Version/s: 0.7, 0.8
• Fix Version/s: 0.9-dev

Description

We used to enable images to be placed in the xdocs/images directory. However, now they are intended to go in the resources/images directory instead. Both methods will work for html pages, but only the latter method for the PDF pages.

Comments

[Rasik Pandey]

I think FOP likes absolute urls. Did you try that?

[David Crossley]

Maybe i wasn't being clear. When forrest sees a URI that begins with "images/*.*" then it uses main/webapp/resources.xmap to look first in xdocs/images/ directory (for backwards compatibility) then in resources/images directory and elsewhere. That works fine for the html output, but not for PDFs. Sure, behind the scenes maybe Forrest maps those to absolute for FOP. However, ...

I wonder if we should mark this issue as "Won't fix" and instead change our documentation and the example "seed sites" to encourage the use of the project resources directory instead instead of xdocs/images/ directory.

Adjusting the documentation for now seems like a great idea. Would have saved my hours ....

Apart from that I'd much prefer if both options work as it is often much easier to store an image for a single page with that page in the same directory while it makes sense to store common images in the resource branch.

In the light of this view it might be a good idea to change the seed site to store project and group icons in the resources branch.

[Ross Gardler]

(some notes I'm working on about 3 issues at once due to Forrest Friday and IRC - need this so we don't forget what we have discovered)

Looking at http://localhost:8888/samples/sample.fo

we see that an xdoc entry of:

<icon height="22" width="26" src="../images/icon.png" alt="feather"/>

gets converted to an fo entry of:

<fo:external-graphic src="D:\tmp\forrest/src/documentation/content/xdocs/samples/../images/icon.png" height="22" width="26"/>

This happens because of document-to-fo.xsl:

<xsl:choose>
        <!-- resources image dir -->
        <xsl:when test="starts-with(string(@src),'images/')">
          <xsl:value-of select="concat($imagesdir,substring-after(@src,'images'))"/>
        </xsl:when>
        <!-- already absolute -->
        <xsl:when test="contains(string(@src),':') or starts-with(string(@src),'/')">
          <xsl:value-of select="@src"/>
        </xsl:when>
        <!-- relative to document -->
        <xsl:otherwise><xsl:value-of select="concat($xmlbasedir,@src)"/></xsl:otherwise>
</xsl:choose>

[Ross Gardler]

So, following on from my notes (previous comment)...

The url "../images/icon.png" falls through to the "otherwise" option.

an url of "images/icon.png" would be matched by the first test, producing:

$imagesdir/icon.png

which resolves to:

{project:resources.images}/icon.png

So...

we have wo possible locations already (and there should be one).

Then we add the problem that the images need to be resolved from multiple possible locations in the src tree (the original issue).

This is *really* messy...

(time for me to sleep now - good luck to those who follow)

[Gavin]

added pathutils.xsl to fo directory, altered document-to-fo.xsl.

[Gavin]

Does somebody want to test this.

[David Crossley]

I tried Gavin's patch "1. fo.diff (10 kb)" but it has no effect as far as i can see.

[David Crossley]

I added a set of examples of linking to images to the 'forrest seed-sample' to demonstrate and explain each situation. This shows that many of the images are broken in the PDF document.
Using localhost:8888/samples/linking.fo is now very helpful.

Regarding the issue comments above. Doing the manipulation of image URLs in the stylesheet seems to be bypassing the sitemap and locationmap handling of these images.

[David Crossley]

Testing the PDF document with r411535 (when the above samples were added) and current head r494757 ... only two images are shown in PDFs: item 4 in the first group and item 3 in the second group. Same in forrest-0.7 release and in current head of forrest_07_branch. Yes, this is with adding the lib/optional/jimi-1.0.jar as described in faq.html#pdf_images

[David Crossley]

Discussion is in various threads, e.g.
 Re: Match Patterns - .xmap and .locationmap.
 http://marc.theaimsgroup.com/?t=116835243200002

[David Crossley]

FOR-187 "Redefine project documentation dirs" talks about part of the solution to image handling.

[Ross Gardler]

Using the example document created by David (forrest seed-sample, http://localhost:8888/samples/linking.pdf) we get the following results with "forrest site":

image liinks 4,5,6 all work as do all three generated PNG's, so the problem cases for "forrest site" are all absolute URLs (i.e. "/images/....")

In "forrest run" no images work (ouch!)

[David Crossley]

For me, in 'forrest run' mode all images work in html. In PDF only two images work (#4 in group 1 and #3 in group 2).

[Ross Gardler]

OK, some success and some failure.

The good news:

I've made a change that means samples 1,2, 4, 5, 6 in group 1 and sample 3 in group 2 now works in both run and site modes

The bad news:

There is no way to make the remaining images work. However, this must have always been the case since the problem is very deep rooted in the way the FO XSLT calculates the path to images and the way some images are generated dynamically.

I propose we now document this limitations and move this to 0.9.

[Ross Gardler]

Change title to reflect the actual situation as it currently stands
Moving to 0.9

[Gavin]

Removing patch available as it does not fix the problem.

[Thorsten Scherler]

After the update to FOP 0.94 it is possible to use any protocol that is known to cocoon.
This allowed to resolve the images via cocoon sitemap and drop the workaround that relied on the file system.