Minimising FOP Runtimes

[Manuel Reyes <Ma...@e-mis.com>]

I have been working on creating a three tier system that per client
requests gets data from a database, pumps this into a PDF via FOP
XSL/XML processing, then sends the resulting PDF back to the client for
display.

This project is reaching its end and creating a 3 or 4 page document
usually takes 4 or 5 seconds (this is just the FOP processing aspect).
Now this is acceptable but there is no harm in hunting down speed
improvements.

Having read through (and implemented any relevant suggestions) the FOP
documentation regarding speed, I thought it would also be a good idea to
speak to the people that use this application on a daily basis, as
experience is invaluable when it comes to this type of thing.

Regards
Manuel

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org

Re: fit table in table-cell

[Chris Bowditch <bo...@hotmail>]

Peter Menzel wrote:

<snip/>

> In the last table cell, I have a nested table with just one row of text.
> What happens is, that my nested table doesn't fill the entire last table-cell
> of the sourrounding table, which causes this bottom line to be shown in 
> the middle of my last table cell.

Couldnt you just turn off border-bottom on the inner table?

<snip/>

Chris



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org

fit table in table-cell

[Peter Menzel <pe...@imise.uni-leipzig.de>]

Hi all fop users,

I have a problem fitting a table in a table-cell.

my table looks like:

+------------+-- ...  --+-------+
|a text with |          +___X___+
|a line break|          |       |
+------------+-- ...  --+-------+

what the picture says, is that in one table-row
I have one or more table-cells with lot of text in them, that causes 
a line break oder more.
In the last table cell, I have a nested table with just one row of text.
What happens is, that my nested table doesn't fill the entire last table-cell
of the sourrounding table, which causes this bottom line to be shown in 
the middle of my last table cell.

in FO the last cell with the nested table, looks like:
<fo:table-cell number-columns-spanned="2">
<fo:block>

<fo:table table-layout="fixed" width="100%">
<fo:table-column column-width="proportional-column-width(1)"/>
<fo:table-body>
<fo:table-row>
<fo:table-cell>
<fo:block>
X
</fo:block>
</fo:table-cell>
</fo:table-row>	

</fo:table-body>
</fo:table>

</fo:block>
</fo:table-cell>

I cannot specify an explicit width of the cells, nor height.
So when I set the height of the inner table to 100%, that
doesnt work..
but thats exactly what I want, the inner table should have the same height as
the table-cell it lies in.

Has somebody an idea about this?

Greetings, Peter


--
peter.menzel@imise.uni-leipzig.de
Institut für Medizinische Informatik, Statistik und Epidemiologie (IMISE)
Universität Leipzig

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org

Re: Minimising FOP Runtimes

[John Austin <jw...@sympatico.ca>]

On Wed, 2003-12-10 at 18:42, J.Pietschmann wrote:
> Manuel Reyes wrote:
> > I have been working on creating a three tier system that per client
> > requests gets data from a database, pumps this into a PDF via FOP
> > XSL/XML processing, then sends the resulting PDF back to the client for
> > display.
> > 
> > This project is reaching its end and creating a 3 or 4 page document
> > usually takes 4 or 5 seconds (this is just the FOP processing aspect).
> > Now this is acceptable but there is no harm in hunting down speed
> > improvements.
> > 
> > Having read through (and implemented any relevant suggestions) the FOP
> > documentation regarding speed, I thought it would also be a good idea to
> > speak to the people that use this application on a daily basis, as
> > experience is invaluable when it comes to this type of thing.
> 
> A time of 4 to 5 seconds for a 3..4 page document is very slow
> for modern machines.
> - Check for warm-up times. It may pay off to reuse the driver object.
> - Check JVM memory settings.
> - If the time includes XSLT, check without it. There are people out
>   there capable of writing *horribly* inefficient XSLT.
> - Invest in a profiler.

I definitely agree with that. Generate the '.fo' separately, say with
command-line Xalan and then generate your PDF with command-line Fop.

This may take more resources than a 'pipeline' approach like Cocoon but
will tell you which step is more expensive. You will need to do this 
anyway if you wish to run a profiler.

Has anyone tried CatchXSL at www.xslprofiler.org ? It seems to work and
has a nice UI but I didn't grok it in the few minutes I played with it.
(I suppose one could intentionally write some bad XSL to demonstrate the
use of this tool.)

Check your 'java' command. There are two versions of the JVM
available(on professional OS's anyway) which are selectable
as 'java -server' and 'java -client' respectively. I found
a benefit of about 10% from the -server version.


> 
> J.Pietschmann
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: fop-user-help@xml.apache.org
-- 
John Austin <jw...@sympatico.ca>

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org

Re: Minimising FOP Runtimes

["J.Pietschmann" <j3...@yahoo.de>]

Stan Pinte wrote:
> by the way, is ir re-entrant? (could be used by multiple threads at the 
> same time to render different pdf's)?

No, the rendering methods are all synchronized. If you want to
take advantage of multiple threads you probably have to implement
a pool.
In most cases however rendering is CPU bound, and you need some
rather expensive iron, perhaps MP, in order to get really something
out of paralell rendering.

J.Pietschmann


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org

Re: Minimising FOP Runtimes

[Stan Pinte <st...@axone.be>]

>
> A time of 4 to 5 seconds for a 3..4 page document is very slow
> for modern machines.
> - Check for warm-up times. It may pay off to reuse the driver object.

by the way, is ir re-entrant? (could be used by multiple threads at the 
same time to render different pdf's)?

> - Check JVM memory settings.
> - If the time includes XSLT, check without it. There are people out
> there capable of writing *horribly* inefficient XSLT.
> - Invest in a profiler.
>
> J.Pietschmann
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: fop-user-help@xml.apache.org
>
>



-- 
Stan Pinte.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org

Re: Minimising FOP Runtimes

["J.Pietschmann" <j3...@yahoo.de>]

Manuel Reyes wrote:
> I have been working on creating a three tier system that per client
> requests gets data from a database, pumps this into a PDF via FOP
> XSL/XML processing, then sends the resulting PDF back to the client for
> display.
> 
> This project is reaching its end and creating a 3 or 4 page document
> usually takes 4 or 5 seconds (this is just the FOP processing aspect).
> Now this is acceptable but there is no harm in hunting down speed
> improvements.
> 
> Having read through (and implemented any relevant suggestions) the FOP
> documentation regarding speed, I thought it would also be a good idea to
> speak to the people that use this application on a daily basis, as
> experience is invaluable when it comes to this type of thing.

A time of 4 to 5 seconds for a 3..4 page document is very slow
for modern machines.
- Check for warm-up times. It may pay off to reuse the driver object.
- Check JVM memory settings.
- If the time includes XSLT, check without it. There are people out
  there capable of writing *horribly* inefficient XSLT.
- Invest in a profiler.

J.Pietschmann


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org