forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clay Leeds <>
Subject Re: Forrest plugin
Date Wed, 06 Oct 2004 16:17:02 GMT
On Oct 6, 2004, at 4:35 AM, Ross Gardler wrote:
> Clay Leeds wrote:
>> On Oct 5, 2004, at 3:54 PM, Clay Leeds wrote:
>>> I'm interested. I've followed these instructions[1] and am a willing  
>>>  participant. Please let me know what I need to do to move OOo  
>>> related  files to a plugin.
> Do "forrest run" using the branch and you will find the start of the  
> docs at http://localhost:8888/docs/plugins.html

after doing a /forrest/, I got a BUILD FAILED with one error in the  
X [0]                                     docs/site:dtd-docs    BROKEN:  
No pipeline matched request: docs/site:dtd-docs
/Users/Shared/_WebDLs/_repos/forrest/src/core/targets/site.xml:43: Java  
returned: 1

Total time: 6 minutes 27 seconds

This was after I followed the procedure outlined here [1]:

> svn switch  
> [optional] forrest available-plugins
> forrest install-plugin
> enter 'IMSManifest' at the prompt

Any ideas? BTW, I am able to successfully run /forrest/ on my main  

> When developing a plugin you can do so directly in the  
> FORREST_HOME/plugins directory. We only need to package it for  
> download once it is complete.

I'll check it out. Do you have a "starter" zip of an OOo plugin to get  
me started? I'd thought you mentioned you had something started, which  
enabled one to use an .sxw file with embedded images.  
Can you get me a copy of that?

To be honest, I don't even know which files will be necessary to build  
the plugin. I assume they're the *openoffice* files (the below files  
except openoffice-writer.sxw) but it would help to pare down the list:

[clay@Clay-Leeds-Computer forrest]$ find . -iname *openoffice*

I'm thinking the plugin should have the following structure:


Is that correct?

>>  From this post[2]:
>>> > For example, I'd like to see Forrest be able to take a .sxw file  
>>> with
>>> > *embedded* pictures, and output the appropriate HTML & PDF files.
>>> Actually, that is one of the enhancements I have made - care to help  
>>> me
>>> do the plugin?
>> Yes! (as you can see, I moved this to a separate topic)
>>> Question. Would this conceivably remove all related   
>>> files (e.g., the openoffice-writer.xsl file) from the forrest   
>>> distribution?
> Yes, the above linked document explains where they go.
>> Then if someone wants to use it, they have to download
>>> it separately?
> Yes, but don't worry about how we enable that right now, we'll package  
> it once it is working.

I would think it would be included in the download, and only be used if  
something matches .sxw...

> The document above describes how it is linked back into Forrest. It  
> essentially uses the new pre-processing sitemap mounting facilities.  
> Therefore, if you are not yet familiar with how this works the docs at  
> http://localhost:8888/docs/your-project.html#sitemap.xmap give an  
> example of how to add a new content type, which is what we are doing  
> here. http://localhost:8888/docs/project-sitemap.html also provides a  
> little info on how the process works.

OK. I'll read up on that again, now that (I think) I have a better  
understanding of how it works.

>>> Or would it still be included in the distribution, but  just not be  
>>> called unless someone included that functionality (or  forgot to  
>>> remove the samples/ dir from their installation :-p)
> In short it works in almost exactly the same way as the dynamic  
> loading and installation of the skins. IN fact most of the packaging  
> code is copied directly from the skin stuff, this needs to be  
> consolidated to remove cut and paste, before it can go back into Trunk  
> (which will be after the 0.6 release).

Always nice to re-use old code!

>>> > The
>>> > HTML files would take screenshots and 'shrink' images down to a  
>>> max  size
>>> > for placement on a page (e.g., max WIDTHxHEIGHT=640x480--user
>>> > configurable, of course), and if the image is larger, provide a
>>> > jump-link (configurable) to the image. The PDF would embed the   
>>> highest
>>> > resolution available for the image, but would also shrink it to   
>>> 'fit' on
>>> > the page.
>>> Not that advanced yet, but embedded images do work in a basic way.
>> How would I go about 'shrinking' the files for the web page. Would I   
>> just specify a width/height (after somehow determining that an  
>> image's  width and height are greater than one of those, apply the  
>> appropriate  ratio)? Does forrest have some type of hook to a program  
>> that can read  images? Should I make it read and then shrink?
> The problem here is that we don't know the size of the browsers  
> display. I think we can discover it through Javascript, but not sure  
> if we want to do that. However, assuming we solve that problem I  
> imagine we can find/create a Cocoon Generator that will do the scaling  
> on the server side for us. First thing will be to get my simple (non  
> scaling) approach to work, then we can do as you suggest (browser  
> scales using height/width) then we'll do the clever stuff.

Personally, I don't want my site to rely on Javascript for any  
functionality. Not that I don't use it, I just don't like to use it for  
what I deem to be 'critical' features (I abhor horizontal scrollbars  
when viewing web pages at 800x600, so ensuring they don't appear to me  
is critical--within reason!). Since I tend to follow the 800x600 rule  
in my web design, I choose 640x480 for the "default" screenshot size,  
and any screens which don't fall into that size should popup a new  
window when clicked. This size should be configurable within (IMHO) so that a web developer could specify  
1024x768 or larger even. I think 640x480 is a good start. 800x600 won't  
work, because there's a navigation menu on the left, and even if there  
weren't one must leave room for the vertical scrollbar.

> However, before we can do that we need to move the existing OOo  
> functionality into a plugin.


> When I did the demo IMSManifest plugin it was simply a case of finding  
> the relevant matchers in Forrests sitemaps and pulling them out into  
> the plugin sitemap. Move all other files that are used (like XSL's),  
> change a few attribute values and viola.
> I'm really busy over the next couple of days, but I will have more  
> time on Friday (I hope). I will do what I can with guidance via email  
> until then.

OK. But if you can get me your 'starter' stuff you've  
started, that would help.

>> Once I have that working, would I have forrest cp   
>> [the-embedded-image(s)] *.sxw/Pictures images/ (or ack!   
>> ../../../resources/images/)
> No copying involved, it extracts the images directly from the sxw  
> archive. Once we have the OOo plugin working I'll put what I have into  
> it and we can go from there.

But won't we need to generate the thumbnail/screenshot images? Those  
will need to be generated, if not copied.

> Ross

Web Maestro Clay
Clay Leeds - <>
Webmaster/Developer - Medata, Inc. - <>
PGP Public Key: <>

View raw message