You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Thomas Sporbeck <th...@exso.de> on 2003/07/08 10:14:27 UTC
[FW:] RE: 0.20.5 release
Hi,
yes, I know there are workarounds. For me it is important to use the XSL:FO-Implementation as "standard" as possible. At the moment we decided not to work with the sources ourselves for programming-capacity and strategical reasons (for me it makes no sense if a houndred programmers implement the same feature separately).
The current pre-release needs about 1 MB RAM per page in our reports - that is indeed no problem if you have a machine with about 256 MB or more and have no other applications loaded while using FOP.
But we're using FOP as add-on to some of our applications and the PCs of the users have 128 MByte maximum and we have to tune each machine carefully with the -Xmx Parameter (otherwise FOP seems to "hang" in some endless loops). If you do this on a stand-alone machine: 32 MB for our reporting engine which produces the .fo-File + 32 MB for Adobe Acrobat or the FOP-Preview + n MB for FOP...
If there would be a way to get the same results with about 512 kByte per page, that would be a big advantage.
The fact is, that we have to (and customers/users simply do) compare the need of memory to other reporting tools as Crystal Reports or commercial XSL:FO-implementations, which use much less memory and are faster.
So if there's a way to implement the suggestions for "lean tables" without refactoring the whole thing, I'd suppose to do so.
It might be a fundamental decision if FOP is a kind of "toolbox" for developers or if it should be an "out of the box-product" for nearly everyone - I think there's so much good ideas in it that everyone should be able to use it.
Thomas Sporbeck
Gesendet am: 08.07.2003 11:34:58
Betreff: RE: 0.20.5 release
Hi Fopers,
I can understand your requirements, but I would like to know what memory
limit you are looking for and what are the filters you two are talking about.
As for me, I have been using FOP for BIG reports (fromm 100 to 2000 pages)
with big tables (like you, more than 500 pages long tables).
I have used some iText Features to deal with forward reference (see the
list archive for more details) and this has been giving me a nice solution.
I can produce a 1500 pages doc on a simple machine with 256Mo in a few
minutes (yes, it swaps) and we use 1 or 2 Go Ram servers for huge documents.
Anyway, we all would welcome some new solution to this problem, but surely
you reckon there has been loads of workarounb in this list ?
Can you be more specific about the performance threshold you are looking for ?
Regards
Cyril
At 09:02 08/07/2003 +0430, you wrote:
>Dear Thomas Sporbeck
>
>It's good to see someone else is using FOP for big reports. I also using
>tables for inventory lists near to 600 pages and my user do not accept
>to use filters. This FOP is killing my user business and if I could not
>find a solution to it, we would trough away the FOP for good, for ever.
>Then it would be a shame on FOP open source developers since I would go
>and buy none open, commercial product.
>
>I would really appreciate if you inform me of your ideas.
>
>Regards
>
>Ali Farahani
>
>-----Original Message-----
>From: Thomas Sporbeck [mailto:th.sporbeck@exso.de]
>Sent: Thursday, June 19, 2003 3:41 PM
>To: fop-dev@xml.apache.org
>Subject: RE: 0.20.5 release
>
>I would agree to Ricardo. We're using tables for inventory lists
>containing about 500 pages. The memory situation in that reports is
>really critical and we cannot force the users to set filters.
>On the other hand: to us it doesn't matter if this enhancement comes
>with 0.20.5 or with a later version (0.20.5a ?), which has of course to
>be decided by the developers and will possibly delay refactoring.
>
>Thomas Sporbeck
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [FW:] RE: 0.20.5 release
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Thomas Sporbeck wrote:
> It might be a fundamental decision if FOP is a kind of "toolbox" for
> developers or if it should be an "out of the box-product" for nearly everyone
It is Open Source. If you find issues and create patches, send
them in. Every contribution is welcome.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [FW:] RE: 0.20.5 release
Posted by Felix Breuer <fe...@fbreuer.de>.
On Tue, 2003-07-08 at 14:31, Bertrand Delacretaz wrote:
> I might be wrong, but I think most users of FOP are using it
> server-side, where resources (especially memory) are more readily
I don't know about most users, but I am using FOP client-side since I do
not have a server.
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [FW:] RE: 0.20.5 release
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mardi, 8 juil 2003, à 10:14 Europe/Zurich, Thomas Sporbeck a écrit :
> ...It might be a fundamental decision if FOP is a kind of "toolbox"
> for developers or if it should be an "out of the box-product" for
> nearly everyone - I think there's so much good ideas in it that
> everyone should be able to use it....
I might be wrong, but I think most users of FOP are using it
server-side, where resources (especially memory) are more readily
available. This might explain your problems, I think little energy has
been spent to optimize FOP's memory requirements.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org