Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: pass (herse.apache.org: local policy)
From: "Gav...." <brightoncomputers@brightontown.com.au>
To: <dev@forrest.apache.org>
Subject: RE: Match Patterns - .xmap and .locationmap.
Date: Sat, 20 Jan 2007 15:54:20 +0900
Message-ID: <012801c73c5f$d0833d50$6b0fa8c0@BrightonComputers.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <009801c733f9$1835f0d0$6b0fa8c0@BrightonComputers.local>
Thread-Index: Accz+Rd7Stsiq0b3Qyynbh6ftDwgLQIYadFA

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