forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clay Leeds <cle...@medata.com>
Subject Re: xml-fop Build Failed
Date Thu, 29 Jul 2004 17:12:29 GMT
On Jul 29, 2004, at 9:12 AM, Nicola Ken Barozzi wrote:
> Clay Leeds wrote:
>> Just checking if anyone had anything further on how I can resolve the 
>> issues building the xml-fop web site. Essentially, I need to figure 
>> out how to deal with (pipelines?) raw content which must have links 
>> to the SOURCE, as well as be transformed into PDF. Examples of how 
>> the *.fo files should be handled can be found here[1], and *.svg 
>> here[2].
>
> Basic rules (we should write them somewhere):
> - All files that Forrest gives the user can be modified by Forrest*
> - *except for the files in the raw dir that are served as-is
> - Forrest will always give the user at least the original file if it 
> cannot process it.
> - if the user asks for the original file+extension it's not guaranteed 
> that Forrest serves the original file

Aha! As I mentioned in a previous POST, I actually have the files in 
both places. Their 'normal' location:

src/documentation/content/xdocs/fo/*.fo
src/documentation/content/xdocs/dev/fo/*.fo
src/documentation/content/xdocs/dev/svg/*.svg

as well as their respective RAW-DIR locations:

src/documentation/resources/fo/*.fo
src/documentation/resources/dev/fo/*.fo
src/documentation/resources/dev/svg/*.svg

(of course, it may be naive of me to assume/hope that this arrangement 
will just work(tm) ;-)

Unfortunately, I get the same BUILD FAILED errors regardless of whether 
the files are in the RAW-DIR, xdocs/ or both (resources/, 
content/xdocs/, or content/xdocs/ *&* resources/).

> Let me give you an example.

Examples are good!

> Currently, given the above rules and the features Forrest has, this is 
> how it should work with svg:
>  original file: myfile.svg
>  ask for myfile.png -> get it transformed from myfile.svg
>  ask for myfile.svg -> get the original svg file
>
> When Forrest will grow, it's more than possible that we have svg 
> output, so the svg could be transformed maybe to add copyright info.
>
> so:
>  original file: myfile.svg
>  ask for myfile.png -> get it transformed from myfile.svg with (c)
>  ask for myfile.svg -> get the transformed from myfile.svg with (c)
>
> If we add pdf support for this we can also have:
>  original file: myfile.svg
>  ask for myfile.png -> get it transformed from myfile.svg with (c)
>  ask for myfile.svg -> get the transformed from myfile.svg with (c)
>  ask for myfile.pdf -> get the transformed from myfile.svg with (c)
>
> This means that
>
> 1) Forrest currently misses some features you need that can be added 
> in the normal Forrest processing (fo,svg->pdf)
>
> 2) We must decide how to make Forrest serve the original files... for 
> example if we want for example the source of the html that is itself 
> in html? Doing it is easy, but the issue is how to manage the URI 
> space.
>
> Thoughts?

Sounds good! And is pretty clear!

>> [1] http://xml.apache.org/fop/examples.html
>> [2] http://xml.apache.org/fop/dev/svg.html
>> [3] 
>> http://homepage.mac.com/webmaestro/xml-fop/xml-fop_files_040729.zip
>> [4] http://marc.theaimsgroup.com/?l=forrest-dev&m=109059296008299&w=2
>> [5]  http://marc.theaimsgroup.com/?l=forrest-dev&m=109042071306416&w=2
> -- 
> Nicola Ken Barozzi                   nicolaken@apache.org
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)

Fair enough! I was hoping someone would just happen to understand what 
I would need, and create the sitemap.xmap pipeline I would need to 
'make it so'. Sounds like I'll have to do some more homework/banging to 
see if I can come up with the pipeline I need. Either that, or we can 
just have a script which runs after /forrest/ and generates the 
necessary files and copies them into their respective dirs.

Web Maestro Clay


Mime
View raw message