Return-Path: Delivered-To: apmail-forrest-dev-archive@www.apache.org Received: (qmail 14108 invoked from network); 6 Oct 2004 18:09:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 6 Oct 2004 18:09:26 -0000 Received: (qmail 47286 invoked by uid 500); 6 Oct 2004 18:09:19 -0000 Delivered-To: apmail-forrest-dev-archive@forrest.apache.org Received: (qmail 47248 invoked by uid 500); 6 Oct 2004 18:09:19 -0000 Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@forrest.apache.org Delivered-To: mailing list dev@forrest.apache.org Received: (qmail 47236 invoked by uid 99); 6 Oct 2004 18:09:19 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from [212.23.3.140] (HELO pythagoras.zen.co.uk) (212.23.3.140) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 06 Oct 2004 11:09:18 -0700 Received: from [82.69.78.226] (helo=[192.168.0.2]) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1CFGDz-000886-40 for dev@forrest.apache.org; Wed, 06 Oct 2004 18:09:15 +0000 Message-ID: <416434C9.7060209@apache.org> Date: Wed, 06 Oct 2004 19:09:13 +0100 From: Ross Gardler User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@forrest.apache.org Subject: Re: Forrest OpenOffice.org plugin References: <89A4EF0D-1721-11D9-AC24-00039385397E@medata.com> <2257BABE-1724-11D9-AC24-00039385397E@medata.com> <4163D885.4040000@apache.org> <280D08F8-17B3-11D9-AEE6-00039385397E@medata.com> In-Reply-To: <280D08F8-17B3-11D9-AEE6-00039385397E@medata.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-Pythagoras-IP: [82.69.78.226] X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Clay Leeds wrote: > 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 > processing: > X [0] docs/site:dtd-docs BROKEN: > No pipeline matched request: docs/site:dtd-docs > [..] > BUILD FAILED > /Users/Shared/_WebDLs/_repos/forrest/src/core/targets/site.xml:43: Java > returned: 1 > > Total time: 6 minutes 27 seconds There was a bug introduced a while back that caused this. It looks like I create the branch when that bug existed. I don't have the time to merge the changes in trunk into the branch right now. However, if you do a "forrest run" everything works fine. >> 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 OpenOffice.org .sxw file with embedded images. > Can you get me a copy of that? No, I seem to have misled you, sorry. I have some enhancements to the OOo integration but it is using the existing system not the proposed plugin system. I was hoping that we could extract the existing functionality into a plugin and then add my enhancements. If you would prefer you are welcome work the other way around and work my enhancements into the existing OOo stuff. When we extract the plugin it will come with it. I'll open an issue and attach a zip of the files I have modified so you can get at them. However, you should be aware that these enhancements need merging with changes that have been made in the OOo stuff here in Forrest, there have been quite a few since I first made my changes so I am not sure how easy this will be. I don't expect it to be a hard job, but who nows what will turn up. > 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: > I'm thinking the plugin should have the following structure: > > OpenOffice/ > OpenOffice/openOffice.xmap > OpenOffice/resources/stylesheets/openoffice-common2forrest.xsl > OpenOffice/resources/stylesheets/openoffice-impress2forrest.xsl > OpenOffice/resources/stylesheets/openoffice-writer2forrest.xsl > OpenOffice/resources/stylesheets/aggregates/openoffice-writer.xml > OpenOffice/resources/stylesheets/aggregates/openoffice-writer.xsl > > Is that correct? Yes. Seems you already pared the list down quite nicely. One small point, the xmap is called "sitemap.xmap" not "openOffice.xmap". >> 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... What do you mean "the download"? The idea is the same as with custom skins, a config file will indicate what plugins are required to build a site (this does not exist as yet). When someone does "forrest *" one of the first actions of Forrest is to ensure it has the necessary plugins available. Any that are missing are automaticaly downloaded and installed. The plugins are not included in the original Forrest download because not everyone needs them and not all plugins will be managed by the Forrest community. >>> 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 Yes, I would agree with you and I think most people here would too. > This size should be configurable within > forrest.properties (IMHO) so that a web developer could specify > 1024x768 or larger even. Yes, that sounds like a reasonable idea. So our XSL will scale the image according to the target screen size set in the properties file. >> 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' OpenOffice.org stuff you've > started, that would help. It's up to you where you want to start, either extracting the existing OOo code into a plugin or merging the changes I have made in the files I attach to the issue into the existing Forrest work. >>> 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. The image is read from the sx* archive using a Cocoon generator. All we need to do is make that generator scale the image accordingly (actually it may be the job of a Transformer rather than a generator). Cocoon itself will cache the results, we need not worry about copying it anywhere (at least this is how I *think* it works I'm no expert on Cocoons internals, so we'll have to check that out we get to this stage). Ross