You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Joshua Lynch <jo...@yahoo.com> on 2003/11/21 18:48:54 UTC
another Site-wide PDF thought
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/
Re: another Site-wide PDF thought
Posted by Peter Hargreaves <pd...@totalise.co.uk>.
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
Re: another Site-wide PDF thought
Posted by Joshua Lynch <jo...@yahoo.com>.
I like the idea of a separate file for describing site-wide and other
multipage pdf and html output. I also like the idea of separating
menus and tabs from links on general principles.
>
> 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
>
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
Re: PDF generation error
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Johan Kok wrote:
> I got the following error with a page that has a jpg included:
>
> org.apache.fop.apps.FOPException: No meaningful layout in block after
> many attempts. Infinite loop is assumed. Processing halted.
>
> The error is eliminated when I comment the figure portion in the
> following section out.
>
>
> <section>
> <title>Championship flyer</title>
> <figure src="images/flyers/tri-aqua03.jpg" alt="TNG Aquathlon and
> Triathlon Championships" width="500"/>
> </section>
>
This means something didn't fit the page, apparently the image. I'm
not sure about the exact reason, try to omit the width and rely on
auto-scaling, or give both width and height, preferably in cm rather
than pixels (PDF is not a bitmap format).
J.Pietschmann
PDF generation error
Posted by Johan Kok <jk...@messianic.dyndns.org>.
I got the following error with a page that has a jpg included:
org.apache.fop.apps.FOPException: No meaningful layout in block after
many attempts. Infinite loop is assumed. Processing halted.
The error is eliminated when I comment the figure portion in the
following section out.
<section>
<title>Championship flyer</title>
<figure src="images/flyers/tri-aqua03.jpg" alt="TNG Aquathlon and
Triathlon Championships" width="500"/>
</section>
Can anybody help?
I will switch the pdf generation off in the mean time.
JK
Re: another Site-wide PDF thought
Posted by "Stephan E. Schlierf" <st...@vsa.de>.
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
Re: another Site-wide PDF thought
Posted by Peter Hargreaves <pd...@totalise.co.uk>.
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?
Pete Hargreaves.