RE: performance problem renedering nested fo-tables

2002-06-21 Thread Argyn Kuketayev
I'll try markers, thanks


> -Original Message-
> From: Chuck Paussa [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 21, 2002 12:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: performance problem renedering nested fo-tables
> 
> 
> Argyn,
> 
> In your case it looks like you should investigate using 
>  and 
>  to get your page headers. Each level of  
> your table 


Re: performance problem renedering nested fo-tables

2002-06-21 Thread Chuck Paussa
Argyn,
In your case it looks like you should investigate using  and 
 to get your page headers. Each level of  your table 
nesting would use a different marker-class-name. The page header can 
then retrieve the contents of that marker (The contents do not print in 
the page, are there only to be retrieved) in the  put something like  Chapter: 
 Section: 


And in the  put
One at the beginning 
of each chapter etc.

Chuck
Argyn Kuketayev wrote:
Do u know any other ways besides nested tables to achieve the same goal?
my goal is whenever the nested section brakes at the page end to have
continuing headers on the next page.
So, Right now for one nested table I've this:
fo:table - with one cell - this is for one "root" table, or a chapter of the
book. so, the chapter title will be on every continuing page.
 fo:table-row 
   fo:table with one cell - this wraps every row of the "root" table, or a
section of the chapter, so when it breakes, its title on the next page 
 fo:table-row 
   fo:block - this contains the content of the row, e.g. coulmn listed
as bullet items
   fo:block - this contains the nested tables, or sub-section of a
chapter
 fo:table with few cells - this is for the nested table, or for a
sub-section of the section, so when it breakes, its title is on the next
page
   fo:table-row - every row contains one row of the sub-section,
e.g. tabular view of columns of the 

   fo:block - this contains one more nested tables, or sub-section of a
chapter
 fo:table with few cells - this is for the nested table, or for a
sub-section of the section, so when it breakes, its title is on the next
page
   fo:table-row - every row contains one row of the sub-section,
e.g. tabular view of columns of the 
row
...
 AND SO ON, there can be any number of nested tables further

I don't know how to get rid of these all nested tables yet. When I tried to
profile FOP, I've seen that one class takes large amount of time to process,
it's FOTreeBuilder.endElement()
Argyn
 




RE: performance problem renedering nested fo-tables

2002-06-21 Thread Argyn Kuketayev
Do u know any other ways besides nested tables to achieve the same goal?

my goal is whenever the nested section brakes at the page end to have
continuing headers on the next page.

So, Right now for one nested table I've this:

fo:table - with one cell - this is for one "root" table, or a chapter of the
book. so, the chapter title will be on every continuing page.
  fo:table-row 
fo:table with one cell - this wraps every row of the "root" table, or a
section of the chapter, so when it breakes, its title on the next page 
  fo:table-row 
fo:block - this contains the content of the row, e.g. coulmn listed
as bullet items
fo:block - this contains the nested tables, or sub-section of a
chapter
  fo:table with few cells - this is for the nested table, or for a
sub-section of the section, so when it breakes, its title is on the next
page
fo:table-row - every row contains one row of the sub-section,
e.g. tabular view of columns of the 

fo:block - this contains one more nested tables, or sub-section of a
chapter
  fo:table with few cells - this is for the nested table, or for a
sub-section of the section, so when it breakes, its title is on the next
page
fo:table-row - every row contains one row of the sub-section,
e.g. tabular view of columns of the 
row
...
  AND SO ON, there can be any number of nested tables further

I don't know how to get rid of these all nested tables yet. When I tried to
profile FOP, I've seen that one class takes large amount of time to process,
it's FOTreeBuilder.endElement()

Argyn




> -Original Message-
> From: Hahn Kurt (CHA) [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 21, 2002 2:34 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: performance problem renedering nested fo-tables
> 
> 
> Oops. I was testing a document without nested tables: Here 
> are the correct
> values:
> PDF (104Kb) : 16 seconds
> xml (511Kb) : 7 seconds
> Sorry
> 
> -Message d'origine-
> De : Hahn Kurt (CHA) [mailto:[EMAIL PROTECTED]
> Envoyé : vendredi, 21. juin 2002 08:27
> À : '[EMAIL PROTECTED]'
> Objet : RE: performance problem renedering nested fo-tables
> 
> 
> Hi,
> I'm generating a very similar document, also with nested 
> tables within a
> main, one-column table. Here's my values:
> PDF (144 Kb, about 30-40 pages): 15 seconds
> just the XML (62 Kb): 7 seconds.
> 
> I wouldn't say that FOP slows down a lot. But: Maybe it's your browser
> that's slowing down. I did my tests from a command-line tool, since it
> wouldn't be very fair to blame FOP only because IE is a lame duck...
> 
> Kurt
> 
> -----Message d'origine-
> De : Argyn Kuketayev [mailto:[EMAIL PROTECTED]
> Envoyé : samedi, 15. juin 2002 00:03
> À : '[EMAIL PROTECTED]'
> Objet : RE: performance problem renedering nested fo-tables
> 
> 
> addition to a previous message: I'm using FOP 0.20.3 with 
> Cocoon 2.0.1. As I
> already stated, time to generate XSL-FO and serialize it to 
> view in the
> browser is under 3 sec. Full time to generate PDF is about 15 seconds.
> 


RE: performance problem renedering nested fo-tables

2002-06-21 Thread Hahn Kurt (CHA)
Oops. I was testing a document without nested tables: Here are the correct
values:
PDF (104Kb) : 16 seconds
xml (511Kb) : 7 seconds
Sorry

-Message d'origine-
De : Hahn Kurt (CHA) [mailto:[EMAIL PROTECTED]
Envoyé : vendredi, 21. juin 2002 08:27
À : '[EMAIL PROTECTED]'
Objet : RE: performance problem renedering nested fo-tables


Hi,
I'm generating a very similar document, also with nested tables within a
main, one-column table. Here's my values:
PDF (144 Kb, about 30-40 pages): 15 seconds
just the XML (62 Kb): 7 seconds.

I wouldn't say that FOP slows down a lot. But: Maybe it's your browser
that's slowing down. I did my tests from a command-line tool, since it
wouldn't be very fair to blame FOP only because IE is a lame duck...

Kurt

-Message d'origine-
De : Argyn Kuketayev [mailto:[EMAIL PROTECTED]
Envoyé : samedi, 15. juin 2002 00:03
À : '[EMAIL PROTECTED]'
Objet : RE: performance problem renedering nested fo-tables


addition to a previous message: I'm using FOP 0.20.3 with Cocoon 2.0.1. As I
already stated, time to generate XSL-FO and serialize it to view in the
browser is under 3 sec. Full time to generate PDF is about 15 seconds.


RE: performance problem renedering nested fo-tables

2002-06-21 Thread Hahn Kurt (CHA)
Hi,
I'm generating a very similar document, also with nested tables within a
main, one-column table. Here's my values:
PDF (144 Kb, about 30-40 pages): 15 seconds
just the XML (62 Kb): 7 seconds.

I wouldn't say that FOP slows down a lot. But: Maybe it's your browser
that's slowing down. I did my tests from a command-line tool, since it
wouldn't be very fair to blame FOP only because IE is a lame duck...

Kurt

-Message d'origine-
De : Argyn Kuketayev [mailto:[EMAIL PROTECTED]
Envoyé : samedi, 15. juin 2002 00:03
À : '[EMAIL PROTECTED]'
Objet : RE: performance problem renedering nested fo-tables


addition to a previous message: I'm using FOP 0.20.3 with Cocoon 2.0.1. As I
already stated, time to generate XSL-FO and serialize it to view in the
browser is under 3 sec. Full time to generate PDF is about 15 seconds.


RE: performance problem renedering nested fo-tables

2002-06-14 Thread Argyn Kuketayev
addition to a previous message: I'm using FOP 0.20.3 with Cocoon 2.0.1. As I
already stated, time to generate XSL-FO and serialize it to view in the
browser is under 3 sec. Full time to generate PDF is about 15 seconds.


performance problem renedering nested fo-tables

2002-06-14 Thread Argyn Kuketayev
Problem:
I have to generate a PDF document/report from the database tables. The
content has a tree-like structure. There's a master resultset, e.g.
Organizations, with several fields. This may contain nested sub-resultsets
for every Organization, e.g. Departments, Affiliates, etc. These
sub-resultsets also may have nested resultsets, and so on. The tree is not
very deep (3-4 layers).

So, the resulting PDF has sections for every Organization, inside it has
subsections for Departments, Affiliates and so on. Like chapters and
sections of a book.

When section doesn't fit the page, on the next page's header there must be a
section name repeated. So, if Affiliate breaks on the page end, then on the
next page header there'll be: "Organization name", "Affiliate name", i.e.
its each parent sections' names too.

I found one way to do it with XSL-FO:
there's a main fo-table(TM) with one column.
Every row's the only cell contains a fo-table(T1), with header
"Oraganization name". This T1 table's rows contain three blocks, one block
is for Organization's fields, the other two blocks are for Departments and
Affiliates, which are also fo-tables. This way whenever the section is
broken into pages, the fo-tables' headers will appear on the next page for
every broken section. E.g. when T1 breakes on page end, TM's and T1's
headers will by rendered on the next page.

This works fine rendering what I want. The issue is with performance. XSL-FO
generation takes 3 seconds. PDF generation takes more than 15 seconds. So,
FOP part is a bottleneck. I strongly suspect that these many embedded tables
and blocks are causing troubles to FOP. I may be wrong though.

I see two options: one is to change FOP to something else (renderex?), the
other one is to change the structure of XSL-FO document.

I'm going to work on the problem these days, since it appears that
performance is going to be the main concern for customers. So, I'll
appreciate any advises very much.

thanks,
Argyn