AW: Is there anybody out there?
Does this happen with the first report after starting the Java VM or later on (after some reports have rendered correctly)? Perhaps you may start FOP in a separate VM and exit it after the report has done, that's not ideal for performance but for stability. Thomas -Ursprüngliche Nachricht- Von: ali farahani [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 16. Juli 2003 15:55 An: [EMAIL PROTECTED] Betreff: Is there anybody out there? To all FOP developers The out of memory problem of FOP is getting critical for our company . So this is an offer for a FOP developer who can fix this problem. If anyone of you can fix this problem please contact me and we can talk about the offer. We are open for the price. Best Regards Ali Farahani - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Just a stupid question ... =P
Ok, I see. There are probably a lot of people that want a free ride to the moon, but that really doesn't make it any more feasible to get them there. I think the main problem is to get them back alive vbg Thomas Sporbeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Just a stupid question ... =P
I think there's no need to quarrel. If you don't love the product you'd just take another an won't comment it. I'm far from understanding FOP deep enough to implement this feature/change (in that way source is source wether it's open or not and it's not easy to join such a project), just: if so many people have problems at the same point, perhaps someone of the masters of FOP has the time (and we all know how expensive free time is) to describe how to implement it or tell us if anyone already has implemented it. As fas as I understood there is a solution for the problem (J. Pietschmann's suggestion) but the developers have different opinions wether to realize it or not - or am I wrong? Thomas Sporbeck ___ Ursprüngliche Nachricht Absender: Bertrand Delacretaz mailto:[EMAIL PROTECTED] Gesendet am: 12.07.2003 20:25:14 Betreff: Re: Just a stupid question ... =P Le Samedi, 12 juil 2003, à 10:27 Europe/Zurich, Jeremias Maerki a écrit : lots-of-good-stuff-snipped/ ...If you think this is a stupid bug, then my all means sit down and try to fix it +1, I could not agree more ;-) -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[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:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 3:41 PM To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [FW:] RE: 0.20.5 release
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. Yes, I agree. But some companies (banking, assurance etc.) have a quite high level of security on their servers - in fact that high that an external administrator has no change to install any piece of software running on a server without some months of testing (and that tests may fail because of a memory lack on the workstations...). Thomas Sporbeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]