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 2006/09/22 15:31:28 UTC
FOR-635 Revisted
Hi All,
Taking yet another look at FOR-635, lets see if we can get this thing
licked.!
Some observations from a 'forrest run' - ( I could have sworn more images
than just one in linking.pdf last time we looked at this, but anyway)
Forrest Run
1. Actual Location is : src/documentation/resources/images/
linking.fo says : <fo:external-graphic src="/images/icon-a.png"/>
linking.html says : <img alt="Icon" src="/images/icon-a.png">
http://localhost:8888/images/icon-a.png - Image appears fine.
Image does NOT appear in linking.pdf
2. Actual Location is : src/documentation/resources/images/sub-dir/
linking.fo says : <fo:external-graphic
src="/images/sub-dir/icon-c.png"/>
linking.html says : <img alt="Icon" src="/images/sub-dir/icon-c.png">
http://localhost:8888/images/sub-dir/icon-c.png - Image appears fine.
Image does NOT appear in linking.pdf
3. Actual Location is : src/documentation/content/xdocs/images/
linking.fo says : <fo:external-graphic src="/images/icon-e.png"/>
linking.html says : <img alt="Icon" src="/images/icon-e.png">
http://localhost:8888/images/icon-e.png - Image appears fine.
Image does NOT appear in linking.pdf
4. Actual Location is : src/documentation/resources/images/
linking.fo says : <fo:external-graphic
src="D:\web\FOR-635/src/documentation/resources/images///icon-a.png"/>
linking.html says : <img alt="Icon" src="images/icon-a.png">
http://localhost:8888/images/icon-a.png - Image appears fine
Image DOES appear in linking.pdf
5. Actual Location is : src/documentation/resources/images/
linking.fo says : <fo:external-graphic src=""/>
linking.html says : <img alt="Icon" src="../images/icon-a.png">
http://localhost:8888/../images/icon-a.png - Image appears fine.
Image does NOT appear in linking.pdf
6. Actual Location is : src/documentation/resources/images/
linking.fo says : <fo:external-graphic src=""/>
linking.html says : <img alt="Icon" src="../../images/icon-b.png">
http://localhost:8888/../../images/icon-b.png - Image appears fine.
Image does NOT appear in linking.pdf
7. Actual Location is : src/documentation/resources/images/
linking.fo says : <fo:external-graphic src="/images/ellipse-2.png"/>
linking.html says : <img alt="Icon" src="/images/ellipse-2.png">
http://localhost:8888/images/ellipse-2.png - Image appears fine.
Image does NOT appear in linking.pdf
1. Actual Location is : src/documentation/content/xdocs/samples/
linking.fo says : <fo:external-graphic src=""/>
linking.html says : <img alt="Icon" src="ellipse.png">
http://localhost:8888/samples/ellipse.png - Image appears fine
Image does NOT appear in linking.pdf
2. Actual Location is : src/documentation/content/xdocs/samples/
linking.fo says : <fo:external-graphic src=""/>
linking.html says : <img alt="Icon" src="cocoon-pyramid.png">
http://localhost:8888/samples/cocooon-pyramid.png - Image appears fine.
Image does NOT appear in linking.pdf
3. Actual Location is : src/documentation/content/xdocs/samples/
linking.fo says : <fo:external-graphic src=""/>
linking.html says : <img alt="Icon" src="icon-d.png">
http://localhost:8888/samples/icon-d.png - Image appears fine.
Image does NOT appear in linking.pdf
Summary: Doing a Forrest Run then and Image number 4 is the ONLY one that
appears in linking.pdf.
This is the only image that is not referenced with a leading '/' -
except the 3 SVG images. It is also the only image the linking.fo sees as
An absolute URL.
Im going to do a run through of the first image first and see if I can spot
anything.
Apologies for being quiet of late, been a bit hectic down here but getting
on Top of things now.
Gav...
RE: FOR-635 Revisted
Posted by "Gav...." <br...@brightontown.com.au>.
> -----Original Message-----
> From: Gav.... [mailto:brightoncomputers@brightontown.com.au]
> Sent: Saturday, 23 September 2006 9:24 AM
> To: dev@forrest.apache.org
> Subject: RE: FOR-635 Revisted
>
> Ok, So I'm just thinking out loud here so if anyone can jump in and
> Fill out any missing steps :)
>
>
>
> Regardless, as David points out, this is not skin specific because we get
> the same results for dispatcher - unless ultimately dispatcher also
> Uses document-to-fo.xsl.
Still thinking out loud here.
So dispatcher uses its own resources.xmap which mimicks the main
resources.xmap, changed only slightly, processing of the images
Seems to be the same.
Dispatcher also has its own document2fo.xsl - yes that's right, it has
Not been renamed document-to-fo.xsl yet.
Either way, this reveals then that the problem COULD therefore be in the
Processing of the image paths inside document-to-fo.xsl and document2fo.xsl
Because if there is a mistake, it is in both of them, meaning that if the
Problem exists in skins and dispatcher, which it does, it does NOT mean that
The fault lies elsewhere as first thought. In fact as the processing of
Images in both resources.xmap seems to be ok, I might try changing
Document-to-fo.xsl around again as I tried originally and see what happens.
I can not see where else pdf processing is happening, so someone stop me if
You think I heading back in the wrong direction - I was put off going here
Before IIRC but seem to be drawn back in again :)
Gav...
>
> Gav...
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.12.8/455 - Release Date: 9/22/2006
RE: FOR-635 Revisted
Posted by "Gav...." <br...@brightontown.com.au>.
Ok, So I'm just thinking out loud here so if anyone can jump in and
Fill out any missing steps :)
> -----Original Message-----
> From: Gav.... [mailto:brightoncomputers@brightontown.com.au]
> Sent: Friday, 22 September 2006 9:31 PM
> To: dev@forrest.apache.org
> Subject: FOR-635 Revisted
>
> Hi All,
>
> Taking yet another look at FOR-635, lets see if we can get this thing
> licked.!
>
> Some observations from a 'forrest run' - ( I could have sworn more images
> than just one in linking.pdf last time we looked at this, but anyway)
>
> Forrest Run
>
>
>
> 1. Actual Location is : src/documentation/resources/images/
> linking.fo says : <fo:external-graphic src="/images/icon-a.png"/>
> linking.html says : <img alt="Icon" src="/images/icon-a.png">
>
> http://localhost:8888/images/icon-a.png - Image appears fine.
>
> Image does NOT appear in linking.pdf
>
Ignoring the rest and just looking at this one.
We have in 'locationmap.xmap'
<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>
In this case we hit the first match and the second match don't we ?
We have in 'sitemap.xmap'
<map:match pattern="**images**">
<map:mount uri-prefix="" src="resources.xmap" check-reload="yes" />
</map:match>
I would say we have a match here so now go to 'resources.xmap'
<!-- handles images local to a contributor directory -->
<map:match pattern="**my-images/**.*">
<map:read src="{lm:project.images.{1}my-images/{2}.{3}}"
mime-type="image/{3}" />
</map:match>
I'm guessing the above is redundant/legacy, do we need it any more ?
We also 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>
As there is no '/' in the match pattern and our xml uses one (<img
src="/images/icon-a.png" alt="Icon" /> ) then this is not a match
And we move on to the next...
<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>
So I guess we have a match here. {1} however would be null so we fall
Into the second when test and end up with
lm:project.images.icon-a.png mime type="image/png"
Are we done here or do we now go on to process ...
<map:match pattern="**.png">
<map:select type="exists">
<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:when test="{lm:project.images.{1}.aart}">
<map:generate type="asciiart-svg"
src="{lm:project.images.{1}.aart}" />
<map:call resource="transform-project2text"/>
<map:serialize type="svg2png" />
</map:when>
<map:when test="{lm:project.images.{1}.png}">
<map:read src="{lm:project.images.{1}.png}"
mime-type="image/png" />
</map:when>
</map:select>
</map:match>
... we match the last when test and again end up with
lm:project.images.icon-a.png mime-type="image/png"
There are a few things I am unsure of.
1. Does sitemap.xmap and locationmap.xmap both get processed or just one of
them?
2. If answer is locationmap.xmap how do we then get to resources.xmap?
3. For skins, document-to-fo.xsl is in use, what gets used for
dispatcher/themes. ?
Content-pdf-link.ft in themes/common says :-
<xsl:param name="defaultVariables" select="'test.html'"/>
<xsl:variable name="skin-img-dir"
select="$defaultVariables/*/*[@name='skin-img-dir']/@value"/>
<xsl:variable name="filename-noext"
select="$defaultVariables/*/*[@name='filename-noext']/@value"/>
<xsl:template match="/">
<forrest:content>
<forrest:part>
<a href="{$filename-noext}.pdf" class="format">
<img class="skin" src="{$skin-img-dir}/pdfdoc.gif"
alt="PDF - icon"/>
<span class="caption">PDF</span>
So what is dispatcher doing looking for skin-img-dir ?
Regardless, as David points out, this is not skin specific because we get
the same results for dispatcher - unless ultimately dispatcher also
Uses document-to-fo.xsl.
Gav...