forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gav...." <brightoncomput...@brightontown.com.au>
Subject RE: Match Patterns - .xmap and .locationmap.
Date Tue, 23 Jan 2007 21:31:32 GMT


> -----Original Message-----
> From: Ross Gardler [mailto:rgardler@apache.org]
> 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:williamstw@gmail.com]
> >> 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


Mime
View raw message