forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Impossible to integrate PDF documents in forrest site?
Date Thu, 22 Aug 2002 13:42:04 GMT

Marc Portier wrote:
> IMHO trail-expressing file-extensions could solve the thing
>   *.doc.pdf could be matched onto a pipeline that starts with an
> xdoc and runs it into a pdf
> 
> as I explained earlier this mechanism could solve more then this
> alone.

Yes.

> 
> as for the other proposals:
> 
>>>IMHO we should just add a matcher that matches every
>>>
>>>    context://include/**
>>>
>>>to
>>>    /content/include/**/*.*
>>>
>>>so that we can easily include static content.
>>
> 
> as easy as the centralized images :-)

;-)

Initially I thought that we would keep the resources separate.
Hence the content/xdocs directory hierarchy.
But since we will be merging all the content types in a single dir, we 
might as well do content/forrest, to indicate that the content will be 
usable by Forrest.

> IMHO this is not how people think about having inlined or
> referenced resources
> having an image or resource-bank is a different issue I guess.
> 
> By the way an absolute reference: /include in our xdocs  will
> open up more trubbels of the tabs-hack kind. (where we prefix the
> tab-hrefs with /forrest/ because it is published like that on
> krysalis.org and outerthought.net?)
> All absolute links we add in our xdocs kill the posibility to
> publish the generated site at any other location then the root.

Ok.

> This we should solve in any case. Maybe a transformer, just
> before the 2html.xsl, that 'relativises' all generated links
> could solve this?

Hmmm...

>>IMHO there must be special matcher for static PDFs
>>(*.pdf) and a separate
>>matcher for Printer-friendly (maybe *.prnt or
>>something like that). Printer
> 
> 
> yes, but calling it *.prnt instead of *.docs.pdf only pushes the
> problem up the chain
> - what if a genuin *.prnt comes along (lame, I know, but true
> :-))
> - how will you print-friendly anything that is not originally in
> xdoc format? in other words: what if you need multiple pipelines
> to pdf, starting from different starting doctypes?
> 
> 
>>friendly does not always mean PDF, it can be a
>>simplified HTML version of
>>the same doc.
>>
> 
> very true.
> Though: I think the skin or the person creating the link in his
> document should decide that, not the sitemap.

Hmmm...
One problem is that we link to future results of the docs, not the docs 
per-se.
IE we link to seeme.html but the source file is seeme.xml.

This is because we link to a URI-space, not the content dir layout.

Now, we have seen that users like a (possibly) 1-1 mapping between dir 
layout and URI space, and I agree with it.
The point is, how do we know what pipeline to match against when 
generating the content?

Marc, now I get your point :-D

ie

   myfile.pipeline.extension

I like it.

>>Another solution is to use an action that will check
>>if there is a file
>>ready to server and if not found then only generate
>>PDF on fly (and maybe
>>store the file).
> 
> don't fully get this...

There is an action that sees if a resource exists.

When I ask for

   myfile.pdf

it can see if it finds

   myfile.pdf

and serve it.
If not it would do:

   /myfile.xml

calling the gen pdf pipeline.

I prefer the previous.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message