forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: images, images and more images
Date Thu, 10 Jul 2003 11:51:52 GMT
On Wed, Jul 09, 2003 at 09:40:40PM -0400, Robert P. J. Day wrote:
>   ok, i've made some progress so i'm just going to write out
> everything i've gone through, and i'd appreciate any clarification
> for questions i have.
>   scenario:  a simple website (variation of avalon-tigris skin),
> with exactly three images, all listed in skinconf.xml:
>   1)  <project-logo>images/tinytux.png</project-logo>
>       <credits>...
>   2)     images/built-with-forrest-button.png
>   3)     images/linuxpower.jpeg
> note that i have to supply 1) and 3), while i've deduced that 2)
> is pulled by forrest out of the forresthome directory so i don't have
> to worry about it.  so far, so good.
>   ok, first point.  i found it initially confusing that the file
> "" defines an explicit project.images-dir directory,
> whose name is conveniently "images/", yet the references to images
> in skinconf.xml must (apparently) be listed relative to the parent
> "resources" directory.  this is not at all intuitive.

What should it be relative to?  If it helps, in 0.6 we're planning to
make it relative to content/.

Currently, project.images-dir locates the images directory in the
_source_.  Forrest then builds a webapp in the standardized format the
the sitemap expects.  In this standardized format, the directory is
always called 'images'.

The easiest way to see how things work is to build a webapp ('forrest
webapp'), and then look at the sitemaps. 

>   second point.  although i mentioned this before, forrest does bad
> things with files that end with ".jpg", but not ".jpeg".  definitely
> non-intuitive.

If you update to CVS Forrest, this should now be fixed.  Forrest will no
longer rewrite extensions.

>   next major point.  i'm assuming that, except for images that i can
> drag out of the forresthome directory (like "Built with Apache Forrest"), 
> i have to supply all images i use, and as i read it, it's sufficient to 
> place those images in src/.../resources/images, right?

Yes, that's where all images should live.

>   (digression:  what is the rationale for the "images/" directory
> under the specific skins/ directory?  so far, i'm ignoring it.  should
> i be doing something with it if i create a custom skin?)

Skin images are for images referenced only by the skin *.xsl files.  It's
for images classed as "presentation", rather than "content".

<snip things-I-hope-are-fixed>

>   here, i need a clarification.  if i go under the new build/
> directory, is my *entire* site upload found under build/site?


> that is, is that directory and all of its subdirectories entirely
> self-contained?  because if i look in the images/ directory in that
> directory, i find exactly:
>   built-with-forrest-button.png
>   tinytux.png
> and *no* linuxpower.jpeg file.  why not?

Is that file ever referred to in the XML?  Forrest spiders the site, so
if it never encountered a reference to 'images/linuxpower.jpeg' it
wouldn't appear in build/site/images/.  Perhaps you are referring to it
as 'images/linuxpower.jpg'?

>   if i look further up, under build/tmp, i find what i assume
> are all sorts of intermediate results, including the directory
> build/tmp/context/resources/images, which contains a pile of
> image files, including my linuxpower.jpeg.  so why is that file
> sitting here but not in my build/site/images directory where it
> would do some good?  if i copy it down manually, then suddenly,
> i have my graphic.  why isn't it being copied there already?
>   and in conclusion, things i'm curious about:
> 1) what does forrest have against files that end with ".jpg"?

.jpg is not the 'canonical' extension for the image/jpeg MIME type.
Cocoon takes responsibility for assigning serialized URLs an appropriate
extension.  In some cases, this is a Good Thing:

 - if you're following best practices [1], image URLs won't have
   extensions at all, but you wouldn't want _serialized_ URLs to have no
   extension.  So here it's good that Cocoon adds an extension.
 - it allows extensions to be centrally managed.  Say I'm writing an
   article about JSP, and serve a sample 'foo.jsp' file as MIME type
   text/plain.  Cocoon will render this as foo.jsp.txt.  Your Tomcat
   instance will then take the hint, and serve it as text, rather than
   interpret it as a JSP (with perhaps disastrous effect).

What I don't understand is why, in your case, Cocoon wasn't writing out a
linuxpowered.jpg.jpeg file, and linking to that.  It would have been
non-optimal, but not a _major_ problem.

Anyway, I've cleared the recognized-MIME-type list now, so this is all
academic :)



> rday

View raw message