You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by "Gav...." <br...@brightontown.com.au> on 2007/01/09 15:18:53 UTC
Match Patterns - .xmap and .locationmap.
Just looking at resources.xmap....
1..<map:match pattern="**/images/**.*">
....<map:select type="exists">
2.....<map:when test="{lm:project.images.{1}/images/{2}.{3}}">
3.......<map:read src="{lm:project.images.{1}/images/{2}.{3}}" mime
type="image/{3}" />
......</map:when>
4.....<map:when test="{lm:project.images.{2}.{3}}">
5.......<map:read src="{lm:project.images.{2}.{3}}" mime-type="image/{3}" />
......</map:when>
....</map:select>
...</map:match>
Just want to walk through this make sure I got it right.
1. If any file exists in an images directory anywhere in the project (or
even above it)
Bearing in mind my understanding is that :-
Project.images == project.content-dir/images
Project.content-dir == xdocs
Therefore project.images == xdocs/images
Also bearing in mind that ** could also contain directory levels.
2. Test for xdocs/images/**/images/**.*
3. read result of 2. and give it a mime type of same extension.
4. test for xdocs/images/**.*
5. read result of 4. and give it a mime type of same extension.
Questions :-
a) - Can the pattern be narrowed down a bit?
b) - The first 'when test' seems wrong to me and two images directories are
hard coded as part of the test, therefore unlikely to ever match anything.
Have I got this wrong ?
c) - The second 'when test' seems better and more likely to match any image
in the xdocs/images/ directory. But, due to the two-asterisk wildcard **
could also introduce further directory levels, is this necessary ?
d) - The locationmap.xml also has similar matching, has the above now been
made redundant anyway or is it still in use in places?
Talking about the Locationmap :-
1....<match pattern="project.images.**.*">
........<select>
2.........<location src="{properties:resources.images}{1}.{2}" />
3.........<location src="{properties:content}../resources/images/{1}.{2}" />
4.........<location src="{properties:content.xdocs}images/{1}.{2}" />
5.........<location src="{properties:content.xdocs}{1}.{2}" />
........</select>
.....</match>
As I understand the above :-
Properties:resources.images == src/documentation/resources/images
Properties:content == src/documentation/content
Properties:content.xdocs == src/documentation/xdocs
Therefore :-
1. Test for xdocs/images/**.* -- Seems we are only testing xdocs ???
2. look in src/documentation/resources/images/**.*
3. look in src/documentation/resources/images/**.*
4. look in src/documentation/xdocs/images/**.*
5. look in src/documentation/xdocs/**.*
Observations :-
a) - Due to the match pattern, neither resources locations will get looked
at.
B) - We still have ** wildcard matching, meaning extra directories both
higher up and lower down the tree, again is this needed quite as liberally
As this, can we not restrict locations a bit more.
I was just wondering also if this liberal sprinklings of ** here was causing
Our headaches of image paths being all over the place, except where we want
Them to be found.
In context, I am again looking into the FOR-635 and other related images not
Showing up. The .fo files are clearly showing that they are being resolved
Wrongly and that maybe we are just being lucky with html matching of these
Images due to dot-dots or something else fixing otherwise masked problems.
I have probably got this all wrong, just trying to clear it in my mind.
Gav...
Re: Match Patterns - .xmap and .locationmap.
Posted by Thorsten Scherler <th...@apache.org>.
On Tue, 2007-01-09 at 23:18 +0900, Gav.... wrote:
> Just looking at resources.xmap....
>
> 1..<map:match pattern="**/images/**.*">
> ....<map:select type="exists">
> 2.....<map:when test="{lm:project.images.{1}/images/{2}.{3}}">
> 3.......<map:read src="{lm:project.images.{1}/images/{2}.{3}}" mime
> type="image/{3}" />
> ......</map:when>
> 4.....<map:when test="{lm:project.images.{2}.{3}}">
> 5.......<map:read src="{lm:project.images.{2}.{3}}" mime-type="image/{3}" />
> ......</map:when>
> ....</map:select>
> ...</map:match>
>
>
> Just want to walk through this make sure I got it right.
To start with, above resolving actually should not be in there but in
the locationmap (it uses 2 locationmap locations). Further since we here
reserving an user url space for forrest we need to add this to the
reserved url pattern list.
>
>
> 1. If any file exists in an images directory anywhere in the project (or
> even above it)
>
> Bearing in mind my understanding is that :-
>
> Project.images == project.content-dir/images
> Project.content-dir == xdocs
>
> Therefore project.images == xdocs/images
>
> Also bearing in mind that ** could also contain directory levels.
Well to find out the real locations of
lm://project.images.{1}/images/{2}.{3} or lm://project.images.{2}.{3}
you need to lookup the locationmap matches for above.
1 (**/images/**.*) really just says any directory before {1} /images/
and having arbitrary directories {2} after and a final extension {3}.
Example that will match:
foo/images/bar.gif
morefoo/images/morebar.jpg
>
> 2. Test for xdocs/images/**/images/**.*
no, wrong
would try to lookup {lm:project.images.{1}/images/{2}.{3}}
Actually I could not find anything in the core that would match this.
>
> 3. read result of 2. and give it a mime type of same extension.
>
yes, right.
> 4. test for xdocs/images/**.*
no, wrong. Test locationmap:
<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>
> 5. read result of 4. and give it a mime type of same extension.
>
right.
>
> Questions :-
>
> a) - Can the pattern be narrowed down a bit?
>
How? By reg exp, yes lots of examples in plugins.
> b) - The first 'when test' seems wrong to me and two images directories are
> hard coded as part of the test, therefore unlikely to ever match anything.
> Have I got this wrong ?
Well, ther will try to lookup a lm location so we cannot make any
statements of hard coded. However I could not find a match in the lm in
the core that would match. Meaning that would be needed to be defined in
the project lm.
>
> c) - The second 'when test' seems better and more likely to match any image
> in the xdocs/images/ directory. But, due to the two-asterisk wildcard **
> could also introduce further directory levels, is this necessary ?
>
If you e.g. categorize your images then you likely end up with a
directory hierarchy in image naming.
> d) - The locationmap.xml also has similar matching, has the above now been
> made redundant anyway or is it still in use in places?
>
> Talking about the Locationmap :-
>
> 1....<match pattern="project.images.**.*">
> ........<select>
> 2.........<location src="{properties:resources.images}{1}.{2}" />
> 3.........<location src="{properties:content}../resources/images/{1}.{2}" />
> 4.........<location src="{properties:content.xdocs}images/{1}.{2}" />
> 5.........<location src="{properties:content.xdocs}{1}.{2}" />
> ........</select>
> .....</match>
>
> As I understand the above :-
>
> Properties:resources.images == src/documentation/resources/images
yes
> Properties:content == src/documentation/content
no.
{properties:content}../resources/images/{1}.{2}
is not equal src/documentation/content
it is equal to src/documentation/content/../resources/images/ which is
equal to src/documentation/resources/images/ which is actually equal to
the first assuming default configuration.
> Properties:content.xdocs == src/documentation/xdocs
>
yes.
you missed one 4) Properties:content.xdocs/images ==
src/documentation/xdocs/images
> Therefore :-
>
> 1. Test for xdocs/images/**.* -- Seems we are only testing xdocs ???
where is the 1. coming from?
> 2. look in src/documentation/resources/images/**.*
> 3. look in src/documentation/resources/images/**.*
> 4. look in src/documentation/xdocs/images/**.*
> 5. look in src/documentation/xdocs/**.*
>
see above.
> Observations :-
>
> a) - Due to the match pattern, neither resources locations will get looked
> at.
such as?
> B) - We still have ** wildcard matching, meaning extra directories both
> higher up and lower down the tree, again is this needed quite as liberally
> As this, can we not restrict locations a bit more.
Hmm, do not know. Why we should not allow arbitrary subdirs?
>
> I was just wondering also if this liberal sprinklings of ** here was causing
> Our headaches of image paths being all over the place, except where we want
> Them to be found.
No it is the multiple fallbacks (most legacy) for image locations. What
we need it is a diet. More true when the dispatcher is further bringing
a source of image resolving (a svg could be defined by a structurer).
>
> In context, I am again looking into the FOR-635 and other related images not
>
> Showing up. The .fo files are clearly showing that they are being resolved
wait. linked! Did you test the url this linking gives?
> Wrongly and that maybe we are just being lucky with html matching of these
> Images due to dot-dots or something else fixing otherwise masked problems.
>
Not sure really. Images should be matched without magic. Max 3 different
places by default (rest should be explained in docs). Let us just agree
on 3 different ways to call an images.
> I have probably got this all wrong, just trying to clear it in my mind.
>
Thanks for bringing this up here.
salu2
> Gav...
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Match Patterns - .xmap and .locationmap.
Posted by David Crossley <cr...@apache.org>.
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 img@src 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 image@src 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 image@src 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...
Re: Match Patterns - .xmap and .locationmap.
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> I think the examples are referenced in FOR-635's comments. I haven't
> tried them though.
> --tim
They are, thanks (and thanks for David for putting them together).
See http://localhost:8888/samples/linking.pdf
and http://localhost:8888/samples/linking.fo
Ross
Re: Match Patterns - .xmap and .locationmap.
Posted by Tim Williams <wi...@gmail.com>.
On 1/23/07, Ross Gardler <rg...@apache.org> wrote:
> 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.
>
> > 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).
I think the examples are referenced in FOR-635's comments. I haven't
tried them though.
--tim
RE: Match Patterns - .xmap and .locationmap.
Posted by "Gav...." <br...@brightontown.com.au>.
> -----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
Re: Match Patterns - .xmap and .locationmap.
Posted by Ross Gardler <rg...@apache.org>.
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.
> 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
RE: Match Patterns - .xmap and .locationmap.
Posted by "Gav...." <br...@brightontown.com.au>.
> -----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.
I have tried this manually by adding in the path to xdocs/images path before
@src and
The result is that any images relevant to xdocs appear in the pdf fine.
I then changed this to add the path to resources/images directory and the
Result is any images there appear fine in the pdf.
The same as for .html, we need to fall through these directories for .fo
Until the image is found and then prepend them to the value-of path.
I have tried all sorts of things to get this to happen without success so
far , even passing a parameter from the match pattern in resources.xmap
Without success. The nearest I have come is create a value in sitemap.xmap
And values there get prepended, but still the same problem, I don't know
How to pass the correct directory across from the locationmap.
Once this is done, the missing SVG images are I think a separate problem
But we'll see.
Any more pointers appreciated.
Gav...
Re: Match Patterns - .xmap and .locationmap.
Posted by Tim Williams <wi...@gmail.com>.
On 1/20/07, Gav.... <br...@brightontown.com.au> wrote:
> Ok, so 11 days without a reply, I realise people are doing
> What interests them, but if anyone understands this please
> Let me in on it so I can continue and try and resolve
> The lack of images in pdfs issue.
>
> I will narrow my questions down a bit :-
>
> In resources.xmap we have
>
> <map:match pattern="images/**.*">
> <map:select type="exists">
> <map:when test="{lm:skin.images.{1}.{2}}">
> <map:read src="{lm:skin.images.{1}.{2}}" mime-type="image/{2}"
> />
> </map:when>
> <map:when test="{lm:project.images.{1}.svg}">
> <map:call resource="pipe-aggregate-svg2png-resource">
> <map:parameter name="path" value="{lm:project.images.{1}.svg}"
> />
> </map:call>
> </map:when>
> <map:otherwise test="{lm:project.images.{1}.{2}}">
> <map:read src="{lm:project.images.{1}.{2}}"
> mime-type="image/{2}" />
> </map:otherwise>
> </map:select>
> </map:match>
>
> <map:match pattern="**images/**.*">
> <map:select type="exists">
> <map:when test="{lm:project.images.{1}.images/{2}.{3}}">
> <map:read src="{lm:project.images.{1}.images/{2}.{3}}"
> mime-type="image/{3}" />
> </map:when>
> <map:when test="{lm:project.images.{2}.{3}}">
> <map:read src="{lm:project.images.{2}.{3}}"
> mime-type="image/{3}" />
> </map:when>
> </map:select>
> </map:match>
>
>
> The first math pattern is simple enough.
>
> The second match pattern is a little more complicated.
>
> Questions.
>
> 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
RE: Match Patterns - .xmap and .locationmap.
Posted by Thorsten Scherler <th...@apache.org>.
On Sat, 2007-01-20 at 15:54 +0900, Gav.... wrote:
> ...
> Talking of dispatcher, document2fo.xsl needs renaming to
> Document-to-fo.xsl as does document2svg etc etc..
>
No, the dispatcher is providing a fo contract (based on above
stylesheet). This way each page can have it own page specific page
design.
http://localhost:8888/resolve.contract.fo.content
> Any pointers appreciated, I have been working on this for
> Weeks.
>
thanks for being sticky.
> Committer != knowitall
>
== tryitall ;)
You normally can find debug/testing matches in my plugin code:
<!--Testing-->
<!--<map:match pattern="resolvePluginContract.*.**">
<map:generate src="build.xml"/>
<map:transform src="resources/stylesheets/test.xsl">
<map:parameter name="document-url" value="{forrest:forrest.plugins}/org.apache.forrest.plugin.output.solr/resources/themes/{properties:dispatcher.fallback.theme}/{1}/{2}.{1}**{lm:resolvePluginThemes.{1}.{2}}-#-{lm:themes/{1}.{1}}"/>
</map:transform>
<map:serialize type="xml"/>
</map:match>-->
the test xsl looks like:
<xsl:param name="document-url"/>
<xsl:template match="/">
<test>
<xsl:value-of select="$document-url"/>
</test>
</xsl:template>
What I do is trying to debug the locationmap matches with this.
Maybe it serves you in this case.
Sorry for being involved in other stuff ATM and not being a bigger help
with this. Do as I do: try and error.
I think we should use the 3 image location that matches and nail down a
image api. The three place where you can put your images and it will
work in forrest (dispatcher included).
Following is a rewrite of all image matching in forrest (naming core,
skins and dispatcher). Best we can do is to keep it simple that a
harmonizing of image locations does not become a nightmare in rewriting
the existing code.
The best is to have
1) core matching - image coming from the project. Like stats, graphs,
etc. included in the docu. Should e.g. match images/etc and ../image.gif
xdocs or {properties:resources.images} (preferred!)
2) skin images - all skin images
3) theme images - all dispatcher theme images
Where 2) and 3) are an extension to 1) and should go into plugins.
salu2
> Gav...
>
>
> > -----Original Message-----
> > From: Gav.... [mailto:brightoncomputers@brightontown.com.au]
> > Sent: Tuesday, 9 January 2007 11:19 PM
> > To: dev@forrest.apache.org
> > Subject: Match Patterns - .xmap and .locationmap.
> >
> > Just looking at resources.xmap....
> >
> > 1..<map:match pattern="**/images/**.*">
> > ....<map:select type="exists">
> > 2.....<map:when test="{lm:project.images.{1}/images/{2}.{3}}">
> > 3.......<map:read src="{lm:project.images.{1}/images/{2}.{3}}" mime
> > type="image/{3}" />
> > ......</map:when>
> > 4.....<map:when test="{lm:project.images.{2}.{3}}">
> > 5.......<map:read src="{lm:project.images.{2}.{3}}" mime-type="image/{3}"
> > />
> > ......</map:when>
> > ....</map:select>
> > ...</map:match>
> >
> >
> > Just want to walk through this make sure I got it right.
> >
> >
> > 1. If any file exists in an images directory anywhere in the project (or
> > even above it)
> >
> > Bearing in mind my understanding is that :-
> >
> > Project.images == project.content-dir/images
> > Project.content-dir == xdocs
> >
> > Therefore project.images == xdocs/images
> >
> > Also bearing in mind that ** could also contain directory levels.
> >
> > 2. Test for xdocs/images/**/images/**.*
> >
> > 3. read result of 2. and give it a mime type of same extension.
> >
> > 4. test for xdocs/images/**.*
> > 5. read result of 4. and give it a mime type of same extension.
> >
> >
> > Questions :-
> >
> > a) - Can the pattern be narrowed down a bit?
> >
> > b) - The first 'when test' seems wrong to me and two images directories
> > are
> > hard coded as part of the test, therefore unlikely to ever match anything.
> > Have I got this wrong ?
> >
> > c) - The second 'when test' seems better and more likely to match any
> > image
> > in the xdocs/images/ directory. But, due to the two-asterisk wildcard **
> > could also introduce further directory levels, is this necessary ?
> >
> > d) - The locationmap.xml also has similar matching, has the above now been
> > made redundant anyway or is it still in use in places?
> >
> > Talking about the Locationmap :-
> >
> > 1....<match pattern="project.images.**.*">
> > ........<select>
> > 2.........<location src="{properties:resources.images}{1}.{2}" />
> > 3.........<location src="{properties:content}../resources/images/{1}.{2}"
> > />
> > 4.........<location src="{properties:content.xdocs}images/{1}.{2}" />
> > 5.........<location src="{properties:content.xdocs}{1}.{2}" />
> > ........</select>
> > .....</match>
> >
> > As I understand the above :-
> >
> > Properties:resources.images == src/documentation/resources/images
> > Properties:content == src/documentation/content
> > Properties:content.xdocs == src/documentation/xdocs
> >
> > Therefore :-
> >
> > 1. Test for xdocs/images/**.* -- Seems we are only testing xdocs ???
> > 2. look in src/documentation/resources/images/**.*
> > 3. look in src/documentation/resources/images/**.*
> > 4. look in src/documentation/xdocs/images/**.*
> > 5. look in src/documentation/xdocs/**.*
> >
> > Observations :-
> >
> > a) - Due to the match pattern, neither resources locations will get looked
> > at.
> > B) - We still have ** wildcard matching, meaning extra directories both
> > higher up and lower down the tree, again is this needed quite as liberally
> > As this, can we not restrict locations a bit more.
> >
> > I was just wondering also if this liberal sprinklings of ** here was
> > causing
> > Our headaches of image paths being all over the place, except where we
> > want
> > Them to be found.
> >
> > In context, I am again looking into the FOR-635 and other related images
> > not
> >
> > Showing up. The .fo files are clearly showing that they are being resolved
> > Wrongly and that maybe we are just being lucky with html matching of these
> > Images due to dot-dots or something else fixing otherwise masked problems.
> >
> > I have probably got this all wrong, just trying to clear it in my mind.
> >
> > Gav...
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.410 / Virus Database: 268.16.7/620 - Release Date: 1/8/2007
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
RE: Match Patterns - .xmap and .locationmap.
Posted by "Gav...." <br...@brightontown.com.au>.
Ok, so 11 days without a reply, I realise people are doing
What interests them, but if anyone understands this please
Let me in on it so I can continue and try and resolve
The lack of images in pdfs issue.
I will narrow my questions down a bit :-
In resources.xmap we have
<map:match pattern="images/**.*">
<map:select type="exists">
<map:when test="{lm:skin.images.{1}.{2}}">
<map:read src="{lm:skin.images.{1}.{2}}" mime-type="image/{2}"
/>
</map:when>
<map:when test="{lm:project.images.{1}.svg}">
<map:call resource="pipe-aggregate-svg2png-resource">
<map:parameter name="path" value="{lm:project.images.{1}.svg}"
/>
</map:call>
</map:when>
<map:otherwise test="{lm:project.images.{1}.{2}}">
<map:read src="{lm:project.images.{1}.{2}}"
mime-type="image/{2}" />
</map:otherwise>
</map:select>
</map:match>
<map:match pattern="**images/**.*">
<map:select type="exists">
<map:when test="{lm:project.images.{1}.images/{2}.{3}}">
<map:read src="{lm:project.images.{1}.images/{2}.{3}}"
mime-type="image/{3}" />
</map:when>
<map:when test="{lm:project.images.{2}.{3}}">
<map:read src="{lm:project.images.{2}.{3}}"
mime-type="image/{3}" />
</map:when>
</map:select>
</map:match>
The first math pattern is simple enough.
The second match pattern is a little more complicated.
Questions.
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 ??
2. Why is there no svg checks and aggregation calls in the second match,
when there is in the first?
Next, in document-to-fo.xsl we have :-
<xsl:variable name="imgpath">
<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>
</xsl:variable>
So, if anything starts off with 'images/' then we only look for it in
resources/images. This is fine.
If something starts off with '/images/' then just use this URL.
According to Apache FOP documentation if the URL is not relative
>From the document, then it must be a full URL, or appended to
>From a base url to give the full path. Note that /images/ is
Referenced in the above code as being 'already absolute' , I
Disagree, this is 'relative from root' . I read this as not
Being good enough from FOP, we need to give the full path.
That's enough for now, if there are more sources for me to look
At please let me know. I am currently testing this using plain
Vanilla 0.8-dev on a see-sample site, dispatcher will come later.
Talking of dispatcher, document2fo.xsl needs renaming to
Document-to-fo.xsl as does document2svg etc etc..
Any pointers appreciated, I have been working on this for
Weeks.
Committer != knowitall
Gav...
> -----Original Message-----
> From: Gav.... [mailto:brightoncomputers@brightontown.com.au]
> Sent: Tuesday, 9 January 2007 11:19 PM
> To: dev@forrest.apache.org
> Subject: Match Patterns - .xmap and .locationmap.
>
> Just looking at resources.xmap....
>
> 1..<map:match pattern="**/images/**.*">
> ....<map:select type="exists">
> 2.....<map:when test="{lm:project.images.{1}/images/{2}.{3}}">
> 3.......<map:read src="{lm:project.images.{1}/images/{2}.{3}}" mime
> type="image/{3}" />
> ......</map:when>
> 4.....<map:when test="{lm:project.images.{2}.{3}}">
> 5.......<map:read src="{lm:project.images.{2}.{3}}" mime-type="image/{3}"
> />
> ......</map:when>
> ....</map:select>
> ...</map:match>
>
>
> Just want to walk through this make sure I got it right.
>
>
> 1. If any file exists in an images directory anywhere in the project (or
> even above it)
>
> Bearing in mind my understanding is that :-
>
> Project.images == project.content-dir/images
> Project.content-dir == xdocs
>
> Therefore project.images == xdocs/images
>
> Also bearing in mind that ** could also contain directory levels.
>
> 2. Test for xdocs/images/**/images/**.*
>
> 3. read result of 2. and give it a mime type of same extension.
>
> 4. test for xdocs/images/**.*
> 5. read result of 4. and give it a mime type of same extension.
>
>
> Questions :-
>
> a) - Can the pattern be narrowed down a bit?
>
> b) - The first 'when test' seems wrong to me and two images directories
> are
> hard coded as part of the test, therefore unlikely to ever match anything.
> Have I got this wrong ?
>
> c) - The second 'when test' seems better and more likely to match any
> image
> in the xdocs/images/ directory. But, due to the two-asterisk wildcard **
> could also introduce further directory levels, is this necessary ?
>
> d) - The locationmap.xml also has similar matching, has the above now been
> made redundant anyway or is it still in use in places?
>
> Talking about the Locationmap :-
>
> 1....<match pattern="project.images.**.*">
> ........<select>
> 2.........<location src="{properties:resources.images}{1}.{2}" />
> 3.........<location src="{properties:content}../resources/images/{1}.{2}"
> />
> 4.........<location src="{properties:content.xdocs}images/{1}.{2}" />
> 5.........<location src="{properties:content.xdocs}{1}.{2}" />
> ........</select>
> .....</match>
>
> As I understand the above :-
>
> Properties:resources.images == src/documentation/resources/images
> Properties:content == src/documentation/content
> Properties:content.xdocs == src/documentation/xdocs
>
> Therefore :-
>
> 1. Test for xdocs/images/**.* -- Seems we are only testing xdocs ???
> 2. look in src/documentation/resources/images/**.*
> 3. look in src/documentation/resources/images/**.*
> 4. look in src/documentation/xdocs/images/**.*
> 5. look in src/documentation/xdocs/**.*
>
> Observations :-
>
> a) - Due to the match pattern, neither resources locations will get looked
> at.
> B) - We still have ** wildcard matching, meaning extra directories both
> higher up and lower down the tree, again is this needed quite as liberally
> As this, can we not restrict locations a bit more.
>
> I was just wondering also if this liberal sprinklings of ** here was
> causing
> Our headaches of image paths being all over the place, except where we
> want
> Them to be found.
>
> In context, I am again looking into the FOR-635 and other related images
> not
>
> Showing up. The .fo files are clearly showing that they are being resolved
> Wrongly and that maybe we are just being lucky with html matching of these
> Images due to dot-dots or something else fixing otherwise masked problems.
>
> I have probably got this all wrong, just trying to clear it in my mind.
>
> Gav...
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.410 / Virus Database: 268.16.7/620 - Release Date: 1/8/2007