DO NOT REPLY [Bug 40495] New: - PDF Report - OutOfMemoryError
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40495. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40495 Summary: PDF Report - OutOfMemoryError Product: Fop Version: 0.92 Platform: Other OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: pdf AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] I am using fop 0.92 (beta) version. I going to generate PDF Report from FO. it is Working fine but when my FO is so large at that time it is giving error java.lang.OutOfMemoryError . Please Give me solution for that. I have also increased memory size also. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Configuration file problems
On Tue, Sep 12, 2006 at 09:37:20PM +0200, Jeremias Maerki wrote: On 12.09.2006 21:13:35 Simon Pepping wrote: Re extensibility: A XML file is validated according to the DTD or schema that it declares (Relax-NG is an exception). The user can put a DTD or schema of his own choice in the user configuration file: !DOCTYPE fop PUBLIC '-//MYSELF//DTD My FOP Configuration XML V1.0//EN' 'http://myserver.mydomain.eu/fop-configuration.dtd' and the parser will validate against it. This means that a user can extend the configuration file at will, and that FOP cannot be assured that the config file is valid. Embedded users can always avoid validation. Yes, but you already assume a non-novice user. If our goal is to have less problems, fewer support requests because of configuration errors, we have to do it fool-proof. You can't rely on everyone putting the DTD or XSD on top of the configuration file. The first time the XML doesn't validate, people remove the schema reference. This sounds like you want to catch user errors in any case. That would be a custom program that applies heuristics based on knowledge of common user errors. For example, 'Do you mean to configure font XXX? I found a font configuration element in a position where FOP will not pick it up.' Class UserConfigDoctor. A possibility besides Java is to do it in XSLT, in the manner of Schematron. Write templates for known suspect XPaths in the file, such as all font elements not in /*/renderers/renderer/fonts. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: Configuration file problems
Jeremias Maerki wrote: Ok, I consider myself defeated concerning the way we handle the configuration file (See recent threads on fop-users). The Avalon configuration approach is very nice for the developer but obviously bullshit in terms of end-user-friendlyness. Back from vacation, a few quick thoughts: The problem seems to be the unexperienced users who *have* to fiddle with the config file for getting basic features working. Possible solutions: - Reduce the need to fiddle with config settings. Some options - Use conventions instead of explicit values - Autodetection and other rule base approaches This concerns probably mainly the baseStuff* settings - Provide a GUI application for changing commonly changed settings - Get commonly changed settings from a file with an easier format, like Java properties Did I get the problem right? J.Pietschmann
Re: Configuration file problems
On Thursday 14 September 2006 07:34, J.Pietschmann wrote: Jeremias Maerki wrote: Ok, I consider myself defeated concerning the way we handle the configuration file (See recent threads on fop-users). The Avalon configuration approach is very nice for the developer but obviously bullshit in terms of end-user-friendlyness. Back from vacation, a few quick thoughts: The problem seems to be the unexperienced users who *have* to fiddle with the config file for getting basic features working. snip/ Did I get the problem right? I had a quick (unscientific) look at the fop-user mailing list. According to my count we had 3 threads in the last 2 months related to config issues. In all cases it was due to an upgrade from 0.20.5 to 0.9x. This made me look at our 'upgrading' page. It does NOT(!) mention that the config file format has changed! Seems to me the easiest fix to all of this is to actually tell users that they also have to change the config file used with 0.20.5 when upgrading. J.Pietschmann Manuel
