Gav.... wrote:
> > From: Ross Gardler
> > Gav.... wrote:
> > >> From: Tim Williams
> > >
> > > <snip>
> > >
> > >>> Questions. (from Gav)
> > >>>
> > >>> 1. - When a URL of /images/icon-a.png is called for as an example, it
> > >> will
> > >>> Fall into this match. So where and how does forrest determine where
> > >> /images/
> > >>> Location actually is. We have possibility of
> > >>>
> > >>> a> in xdocs/images
> > >>> b> in resources/images/
> > >>> c> in anotherLocation/images/
> > >>>
> > >>> The when tests check in project.images which is defaulted to
> > >>> resources/images. If /images/icon-a.png is meant to be
> > >>> xdocs/images/icon-a.png where is this matched ??
> > >> take a look at the locationmap.xml file and look for the pattern
> > >> "project.images.**.*" this is where they actually get resolved to a
> > >> physical location. I don't know the rest of your questions without
> > >> looking into it a bit to refresh myself and I haven't the time right
> > >> now.
> > >> --tim
> > >
> > > Hi Tim, yep got that thanks.
> > >
> > >
> > >
> > > <match pattern="project.images.**.*">
> > > <select>
> > > <location src="{properties:resources.images}{1}.{2}" />
> > > <location src="{properties:content}../resources/images/{1}.{2}"
> > />
> > > <location src="{properties:content.xdocs}images/{1}.{2}" />
> > > <location src="{properties:content.xdocs}{1}.{2}" />
> > > </select>
> > > </match>
> > >
> > >
> > > The above is working fine for .html pages etc but does not work for pdf
> > > images.
> > >
> > > From what I can tell we need to implement this same feature for the
> > > Document-to-fo.xsl :-
> > >
> > > <!-- already absolute -->
> > > <xsl:when test="contains(string(@src),':') or
> > > starts-with(string(@src),'/')">
> > > <xsl:value-of select="@src"/>
> > > </xsl:when>
> > >
> > > I feel that the 'value-of select' needs the relevant location (whichever
> > one
> > > of the 4 above) putting in before the @src using concat. This will then
> > make
> > > The src a full path location and fop will be happy.
> >
> > No.
> >
> > The output of document-to-fo.xsl should be an XSLT/FO document with
> > client focussed URLs. i.e. just what they are in the original XDoc. the
> > "project.images.**" path is an internal one for the locationmap.
>
> I was hoping to prepend the project.images.** path into the .fo file yb
> Using document-to-fo.xsl. I may be confused, xmlgraphics documentation
> Is not clear to me on this, but I gathered that .fo files that reference
> External sources such as graphics files needed a basedir to work from
> If they were relative references. To me, relative references means anything
> That does not contain a full path to the image, /resources/images or
> /xdocs/images within a .fo file results in no image, with something like
> D:/path/to/resources/images/ in .fo then the image will appear every time.
>
> Now I know we can not hard code this, but using whatever output from
> Project.images.** gives and then adding the relative reference to that
> Would seem to be a solution.
Yes but it is more complex than that. Both the resources.xmap
and the locationmap are involved in determining the location
of image resources. However, see below.
> We should be looking in 4 possible locations.
>
> 1. The user defined or default project.images directory.
> 2. If not there then try the provided /src/resources/images directory.
> 3. If not there then try the provided backwards compatible src/xdocs/images
> 4. If not there then it must be in same directory as the source file.
Or relative to it.
Prior to that it might also be generated from SVG-to-PNG etc.
> The locationmap does more than that. It is currently possible that an image
> May lie say one or more levels above the source file location. ( **images**
> match etc)
> This may not Be any of the locations listed above. This is what to me is
> making it hard To narrow down the possible list of locations for the image
> To give to .fo
Don't forget that you need to interpret the resources.xmap
and the locationmap in conjunction.
I see that the section samples/linking.html#images might need
a stronger hint (though it cannot hope to explain it all).
That sitemap does various matches and also handles svg-to-png
and asciiart. It used to do all the work, nowadays it consults
the locationmap as well. Too complex.
Consider the result from http://localhost:8888/samples/linking.xml
It has [EMAIL PROTECTED] with the values as they were in the source xdoc.
At the time that the browser displays http://localhost:8888/samples/linking.html
Cocoon handles those [EMAIL PROTECTED] with the resources.xmap/locationmap etc.
That works fine.
However for http://localhost:8888/samples/linking.fo
See webapp/sitemap.xmap line 669 in today's head r499193
where it transforms the internal document xml into fo.
This has very crude handling of [EMAIL PROTECTED] URLs, where the
document-to-fo.xsl transformer tries to handle by itself
the various locations. Nowhere near as powerful as the
resources.xmap/locationmap combination and especially does
not handle the potential svg2png variants.
Somehow we need to resolve the image @src URLs just before
line 669. I have no idea how.
-David
> I think if it is not in any of the 4 locations then don't bother looking
> Elsewhere, these are plenty enough locations and users should be
> Educated to put images here. I think this has been touched on many
> Times see
> http://issues.cocoondev.org/jira//secure/ViewIssue.jspa?key=FOR-187 from 2
> years ago.
>
> Of course I probably got all this wrong and relative as you suggest should
> Work, in which case I've been looking at it from the wrong angle.
>
> I'll wait now and see what others can come up with. I may send an email
> To fop/batik just to confirm/deny my interpretation of external
> Graphics files needing full path URLs.
>
> Gav...
