forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephan E. Schlierf" <>
Subject Re: another Site-wide PDF thought
Date Wed, 26 Nov 2003 07:50:02 GMT
Peter Hargreaves schrieb:
> On Fri, 2003-11-21 at 17:48, Joshua Lynch wrote:
>>Forrest's site-wide PDF feature is very useful to me but it would be
>>even better if I could 'turn on', or somehow optionally specify, page
>>breaking between web pages.  Another handy feature for me would be to
>>automatically generate tab-wide PDFs.  By that I mean generate a PDF
>>that includes all the pages on a tab.
>>My primary Forrest project is a use case website and I would like to be
>>able to print all the use cases or just those use cases on the same tab
>>without having some use cases on the same pages.
>>Josh Lynch
>>Do you Yahoo!?
>>Free Pop-Up Blocker - Get it now
> Hi Josh, You are close to my thoughts on this one. But in my case I am
> also interested in using the DocBook DTD.
> I've noticed a while ago that the site wide PDF just simply merges all
> the pages by putting sections in sections in sections ad nausium (might
> have changed now). While technically brilliant, I don't find this
> useful yet. It would be better if it used the element names from
> Forrest site.xml (perhaps it does now). The following is what I have in
> mind.
> My whole site might represent a <book/>. The tabs might represent <part/>s
> of the <book/>. The main items in the left menu might represent
> <chapter/>s or <article/>s. The sub items in the left menu might be
> <section/>s. My <chapter/>s and <article/>s would be xml files.
> When requesting a PDF document I would like to be able to request the
> whole <book/>, or a <part/> of the <book>, or a <chapter/> of
> <part/>, or an <article/> of a <part/>, or a <section/> of a
> <chapter/>, etc. I'd like these all to be available, requested by url.
> To achieve this I would want to put my <chapter/>s and <article/>s in
> separate xml files. The introductory bits of <book/> and <part/>s,
> would also be in files.
> The forrest site.xml file would be structured using element names of
> <book>, <part>, <chapter>, <article>, <etc>. These elements
> reference all the xml files of the <book/> showing how to build it.
> Because I want the <book> structure displayed as tabs and menus, I need
> to be able to request starting points in both HTML and in PDF These
> starting points would be treated differently. A starting point in PDF
> would show all the contents from that point downward merging files as
> necessary. A starting point in HTML might or might not merge files
> downward throughout the structure. It would only merge the lower levels
> of structure if the lower levels are not displayed as menu items,
> and therefore not otherwise be available.
> Are these thoughts useful to you Josh? Is anyone else thinking this way?

I agree to the need of generating pdf- or html-files site-wide, 
tab-wide, "chapter"-wide - o.k., the user should determine which files 
should additionally be included in one pdf- or html-file.
I also agree with you that it should be possible to lay this down in a 
separate xml-file - but I'm not quite sure whether site.xml is the right 
place. For me site.xml now is kind of a logical mixture between the 
structure of my site (menus, submenus and so on) and a central place to 
define links (internal and external).
What do you think of "splitting" site.xml into one xml-file, where I 
define menus, submenus, even tabs (so tabs.xml would be obsolete) and - 
of course - the handling of pdf- and html-files as you described above. 
Another xml-file - let's call it "links.xml" - could contain all my 
links to internal and external sites.


View raw message