forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hargreaves <...@totalise.co.uk>
Subject Re: another Site-wide PDF thought
Date Wed, 26 Nov 2003 23:42:41 GMT
On Wed, 2003-11-26 at 07:50, Stephan E. Schlierf wrote:
> 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
> >>http://companion.yahoo.com/
> > 
> > 
> > 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 a
> > <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 would
> > 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.
> 
> Stephan
> 
I quite like the idea of a navigation.xml (possibly site.xml with tabs.xml
obsolete) that describes the navigation hierarchy. The skin should
decide how to put navigation items into tabs, tabs under tabs, left items, left
sub-items, etc.

Isn't the navigation hierarchy analogous to a site/book table of
contents, and therefore the same as the site/book structure? After all
what do you navigate if it isn't the structure?

And, if a table of contents can be generated form a whole book, surely
a book can be assembled using a table of contents?

When pieces of the site are to be assembled in a different way, that can
be done with add-hoc simple aggregation files.

When referring to pieces of the book/site, surely xpath like
expressions should be used to identify items in navigation.xml (as is
already done with site:...). Perhaps it should be nav:...

I think external references should be in x-navigation.xml

Peter



Mime
View raw message