forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Portier" <...@outerthought.org>
Subject RE: Impossible to integrate PDF documents in forrest site?
Date Thu, 22 Aug 2002 12:14:06 GMT

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/**
> >
> > to
> >     /content/include/**/*.*
> >
> > so that we can easily include static content.
>

as easy as the centralized images :-)
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.

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.

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

regards,
-marc=


Mime
View raw message