forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
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.


> as for the other proposals:
>>>IMHO we should just add a matcher that matches every
>>>    context://include/**
>>>    /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
> and
> All absolute links we add in our xdocs kill the posibility to
> publish the generated site at any other location then the root.


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


>>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.

One problem is that we link to future results of the docs, not the docs 
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



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


it can see if it finds


and serve it.
If not it would do:


calling the gen pdf pipeline.

I prefer the previous.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message