> -----Original Message----- > From: Ross Gardler [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 23 January 2007 11:04 PM > To: dev@forrest.apache.org > Subject: Re: Match Patterns - .xmap and .locationmap. > > Gav.... wrote: > > > >> -----Original Message----- > >> From: Tim Williams [mailto:[EMAIL PROTECTED] > >> Sent: Saturday, 20 January 2007 9:39 PM > >> To: dev@forrest.apache.org > >> Subject: Re: Match Patterns - .xmap and .locationmap. > > > > <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. 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. 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 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... > > > Once this is done, the missing SVG images are I think a separate problem > > But we'll see. > > > > Any more pointers appreciated. > > Can you please provide an example of an image that is not working, so > that I can trace this. better still, point at an example in SVN that > fails (add it to our example docs if necessary). > > Ross
