Re: OutOfMemoryError: Java heap space
To reply to this thread Re: OutOfMemoryError: Java heap space Thu, 03 Jul 2014 14:35:00 GMT to Chandone For my part, for the same problem, I noticed I had the 32bits version of JRE. I installed the 64 bits version and no more OutOfMemoyError. Regards JP - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: OutOfMemoryError: Java heap space
Hello, This is an old thread but this problem is more newsworthy than ever. I'm running FOP 1.1 (trunk didn't help either), my XSL-FO is only 500 KB large, and /*only text!*/, I allocated 7(!)GB to my JVM on a 64 bits Windows 7 and despite all that, FOP, after reeling in a long time, throws a java.lang.OutOfMemoryError: Java heap space exception when generating a PDF. Oh, and I just can't split my XSL-FO into several page-sequences, it's a one-block text that doesn't allow page breaks. There aren't any page references either. So that's it. No workaround works and I'm stuck being unable to generate a all-text PDF from a 500 KB XSL-FO with 7GB allocated memory. Here is the stack, for what it's worth: at org.apache.fop.layoutmgr.BreakingAlgorithm.createNode(BreakingAlgorithm.java:712) at org.apache.fop.layoutmgr.BreakingAlgorithm.addBreaks(BreakingAlgorithm.java:1151) at org.apache.fop.layoutmgr.BreakingAlgorithm.considerLegalBreak(BreakingAlgorithm.java:965) at org.apache.fop.layoutmgr.BreakingAlgorithm.handlePenaltyAt(BreakingAlgorithm.java:818) at org.apache.fop.layoutmgr.BreakingAlgorithm.handleElementAt(BreakingAlgorithm.java:754) at org.apache.fop.layoutmgr.BreakingAlgorithm.findBreakingPoints(BreakingAlgorithm.java:553) at org.apache.fop.layoutmgr.BreakingAlgorithm.findBreakingPoints(BreakingAlgorithm.java:503) at org.apache.fop.layoutmgr.inline.LineLayoutManager.findOptimalBreakingPoints(LineLayoutManager.java:895) at org.apache.fop.layoutmgr.inline.LineLayoutManager.createLineBreaks(LineLayoutManager.java:815) at org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:635) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:288) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:497) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:288) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:238) at org.apache.fop.layoutmgr.list.ListItemLayoutManager.getNextKnuthElements(ListItemLayoutManager.java:221) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:497) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:288) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:238) at org.apache.fop.layoutmgr.list.ListBlockLayoutManager.getNextKnuthElements(ListBlockLayoutManager.java:105) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements(BlockLayoutManager.java:141) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:288) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:497) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:288) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:238) at org.apache.fop.layoutmgr.list.ListItemLayoutManager.getNextKnuthElements(ListItemLayoutManager.java:221) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:497) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:288) Any help would be highly appreciated. Cheers, Erwann -- View this message in context: http://apache-fop.1065347.n5.nabble.com/OutOfMemoryError-Java-heap-space-tp4271p40861.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: Java Heap
Hi Georg, I second what Andrey says. I was getting out of memory issues when ever I tried to iterate over 5000 elements within a single page sequence. I solved this by splitting the big parts of the document into separate page sequences as FOP releases memory after each page sequence. Good luck Georg Datterl georg.datt...@geneon.de 09/06/2010 16:35 Hi Andrey, Other than that you can: · Decrease the number of pages in one page-sequence (means changing the fo file). · Change the gc-paramter of your VM. Continual GC keeps the system from GCing until timeout ( parameter when starting fop) · If you have lots of images, all of them used once, you can turn off image caching. ( parameter when starting fop) The overflow messages you see are not memory overflows but print area overflows. Basically you have a block which contains more text than fits into the block. The text is printed beyond the border of the block and a warning is generated. If the space, where the text is printed into is empty otherwise, there’s no harm done and everything is fine. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH:www.irs-nbg.de Willmy PrintMedia GmbH:www.willmy.de Willmy Consult Content GmbH: www.willmycc.de Von:Eric Douglas [mailto:edoug...@blockhouse.com] Gesendet: Mittwoch, 9. Juni 2010 17:18 An: fop-users@xmlgraphics.apache.org Betreff: RE: Java Heap You can't generate big files, or you need more memory. More memory could be referring to either your physical system memory or your allocated Java memory. This should have norhing to do with your line overflows. Make text smaller or blocks bigger. In my usage, I just put a condition that would tell the user don't do that if they try to print a report over like 1000 pages. I'm not sure where the memory cutoff would be, but they should normally never need giant reports. A report that big typically means they need to enter more criteria to limit results. I'm sure there's a workaround to print giant reports if there is a need. Maybe you could try creating multiple PDFs and combining? Maybe there's a fix in the Trunk? I haven't bothered to figure out how because it's easier to say don't do that. To figure out why you're overflowing, someone would most likely need to see your actual XML/XSL/FO code. I have mine dynamically setting the font size and block size to make sure it fits. From:Andrey Skrypnik [mailto:askryp...@meritservus.com] Sent: Wednesday, June 09, 2010 10:57 AM To: fop-users@xmlgraphics.apache.org Subject: Java Heap Hi guys, I’m using FOP 0.95 i when i try to generate a big file i received: SEVERE: Servlet.service() for servlet meritservus threw exception java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Arrays.java:3209) at java.lang.String.init(String.java:215) at java.lang.StringBuffer.toString(StringBuffer.java:585) at java.io.StringWriter.toString(StringWriter.java:193) but before i have a huge amount of rows: WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.688 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.688 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.813 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 12906mpt. (fo:block, COMMUNICATIONS) 17:16:09.985 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 12906mpt. (fo:block, COMMUNICATIONS) 17:16:10.423 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 14890mpt. (fo:block, SAMPLE_PORT_USD) Please, help me, how I can fix it! Thanks a lot! __ Information from ESET NOD32 Antivirus, version of virus signature database 5184 (20100609) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com This message and any attachments are intended for the persons named as addressees only and may contain confidential information. In addition they may be protected by copyright. If you receive
AW: AW: Java Heap
Hi Lea, See the first bullet in my list. But that might not be possible if the fo file is provided by external sources. I just remembered reading about an experimental feature which made fop release memory while still in the same page-sequence. You can search the fop-dev archive for a message from Ben Wuest, posted around 3.6.2009, 22:48, subject: Apache FOP 0.95 Patch. This patch requires a modification of FOP, but is based on FOP 0.95, not trunk. Actually, I have no idea if the patch made it into trunk. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.dehttp://www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.dehttp://www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.dehttp://www.willmy.de Willmy Consult Content GmbH: www.willmycc.dehttp://www.willmycc.de Von: Lea Farmer [mailto:lfar...@companieshouse.gov.uk] Gesendet: Donnerstag, 10. Juni 2010 11:18 An: Georg Datterl; fop-users@xmlgraphics.apache.org Betreff: Re: AW: Java Heap Hi Georg, I second what Andrey says. I was getting out of memory issues when ever I tried to iterate over 5000 elements within a single page sequence. I solved this by splitting the big parts of the document into separate page sequences as FOP releases memory after each page sequence. Good luck Georg Datterl georg.datt...@geneon.de 09/06/2010 16:35 Hi Andrey, Other than that you can: · Decrease the number of pages in one page-sequence (means changing the fo file). · Change the gc-paramter of your VM. Continual GC keeps the system from GCing until timeout ( parameter when starting fop) · If you have lots of images, all of them used once, you can turn off image caching. ( parameter when starting fop) The overflow messages you see are not memory overflows but print area overflows. Basically you have a block which contains more text than fits into the block. The text is printed beyond the border of the block and a warning is generated. If the space, where the text is printed into is empty otherwise, there’s no harm done and everything is fine. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.dehttp://www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.dehttp://www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.dehttp://www.willmy.de Willmy Consult Content GmbH: www.willmycc.dehttp://www.willmycc.de Von: Eric Douglas [mailto:edoug...@blockhouse.com] Gesendet: Mittwoch, 9. Juni 2010 17:18 An: fop-users@xmlgraphics.apache.org Betreff: RE: Java Heap You can't generate big files, or you need more memory. More memory could be referring to either your physical system memory or your allocated Java memory. This should have norhing to do with your line overflows. Make text smaller or blocks bigger. In my usage, I just put a condition that would tell the user don't do that if they try to print a report over like 1000 pages. I'm not sure where the memory cutoff would be, but they should normally never need giant reports. A report that big typically means they need to enter more criteria to limit results. I'm sure there's a workaround to print giant reports if there is a need. Maybe you could try creating multiple PDFs and combining? Maybe there's a fix in the Trunk? I haven't bothered to figure out how because it's easier to say don't do that. To figure out why you're overflowing, someone would most likely need to see your actual XML/XSL/FO code. I have mine dynamically setting the font size and block size to make sure it fits. From: Andrey Skrypnik [mailto:askryp...@meritservus.com] Sent: Wednesday, June 09, 2010 10:57 AM To: fop-users@xmlgraphics.apache.org Subject: Java Heap Hi guys, I’m using FOP 0.95 i when i try to generate a big file i received: SEVERE: Servlet.service() for servlet meritservus threw exception java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Arrays.java:3209) at java.lang.String.init(String.java:215) at java.lang.StringBuffer.toString(StringBuffer.java:585) at java.io.StringWriter.toString(StringWriter.java:193) but before i have a huge amount of rows: WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.688 WARN [http-8080-3
Java Heap
Hi guys, I'm using FOP 0.95 i when i try to generate a big file i received: SEVERE: Servlet.service() for servlet meritservus threw exception java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Arrays.java:3209) at java.lang.String.init(String.java:215) at java.lang.StringBuffer.toString(StringBuffer.java:585) at java.io.StringWriter.toString(StringWriter.java:193) but before i have a huge amount of rows: WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.688 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.688 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.813 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 12906mpt. (fo:block, COMMUNICATIONS) 17:16:09.985 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 12906mpt. (fo:block, COMMUNICATIONS) 17:16:10.423 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 14890mpt. (fo:block, SAMPLE_PORT_USD) Please, help me, how I can fix it! Thanks a lot!
RE: Java Heap
You can't generate big files, or you need more memory. More memory could be referring to either your physical system memory or your allocated Java memory. This should have norhing to do with your line overflows. Make text smaller or blocks bigger. In my usage, I just put a condition that would tell the user don't do that if they try to print a report over like 1000 pages. I'm not sure where the memory cutoff would be, but they should normally never need giant reports. A report that big typically means they need to enter more criteria to limit results. I'm sure there's a workaround to print giant reports if there is a need. Maybe you could try creating multiple PDFs and combining? Maybe there's a fix in the Trunk? I haven't bothered to figure out how because it's easier to say don't do that. To figure out why you're overflowing, someone would most likely need to see your actual XML/XSL/FO code. I have mine dynamically setting the font size and block size to make sure it fits. From: Andrey Skrypnik [mailto:askryp...@meritservus.com] Sent: Wednesday, June 09, 2010 10:57 AM To: fop-users@xmlgraphics.apache.org Subject: Java Heap Hi guys, I'm using FOP 0.95 i when i try to generate a big file i received: SEVERE: Servlet.service() for servlet meritservus threw exception java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Arrays.java:3209) at java.lang.String.init(String.java:215) at java.lang.StringBuffer.toString(StringBuffer.java:585) at java.io.StringWriter.toString(StringWriter.java:193) but before i have a huge amount of rows: WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm: 388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.688 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm: 388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.688 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm: 388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.813 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm: 388 - Line 1 of a paragraph overflows the available area by 12906mpt. (fo:block, COMMUNICATIONS) 17:16:09.985 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm: 388 - Line 1 of a paragraph overflows the available area by 12906mpt. (fo:block, COMMUNICATIONS) 17:16:10.423 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm: 388 - Line 1 of a paragraph overflows the available area by 14890mpt. (fo:block, SAMPLE_PORT_USD) Please, help me, how I can fix it! Thanks a lot! __ Information from ESET NOD32 Antivirus, version of virus signature database 5184 (20100609) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
AW: Java Heap
Hi Andrey, Other than that you can: · Decrease the number of pages in one page-sequence (means changing the fo file). · Change the gc-paramter of your VM. Continual GC keeps the system from GCing until timeout ( parameter when starting fop) · If you have lots of images, all of them used once, you can turn off image caching. ( parameter when starting fop) The overflow messages you see are not memory overflows but print area overflows. Basically you have a block which contains more text than fits into the block. The text is printed beyond the border of the block and a warning is generated. If the space, where the text is printed into is empty otherwise, there's no harm done and everything is fine. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.dehttp://www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH: www.irs-nbg.dehttp://www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.dehttp://www.willmy.de Willmy Consult Content GmbH: www.willmycc.dehttp://www.willmycc.de Von: Eric Douglas [mailto:edoug...@blockhouse.com] Gesendet: Mittwoch, 9. Juni 2010 17:18 An: fop-users@xmlgraphics.apache.org Betreff: RE: Java Heap You can't generate big files, or you need more memory. More memory could be referring to either your physical system memory or your allocated Java memory. This should have norhing to do with your line overflows. Make text smaller or blocks bigger. In my usage, I just put a condition that would tell the user don't do that if they try to print a report over like 1000 pages. I'm not sure where the memory cutoff would be, but they should normally never need giant reports. A report that big typically means they need to enter more criteria to limit results. I'm sure there's a workaround to print giant reports if there is a need. Maybe you could try creating multiple PDFs and combining? Maybe there's a fix in the Trunk? I haven't bothered to figure out how because it's easier to say don't do that. To figure out why you're overflowing, someone would most likely need to see your actual XML/XSL/FO code. I have mine dynamically setting the font size and block size to make sure it fits. From: Andrey Skrypnik [mailto:askryp...@meritservus.com] Sent: Wednesday, June 09, 2010 10:57 AM To: fop-users@xmlgraphics.apache.org Subject: Java Heap Hi guys, I'm using FOP 0.95 i when i try to generate a big file i received: SEVERE: Servlet.service() for servlet meritservus threw exception java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Arrays.java:3209) at java.lang.String.init(String.java:215) at java.lang.StringBuffer.toString(StringBuffer.java:585) at java.io.StringWriter.toString(StringWriter.java:193) but before i have a huge amount of rows: WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.688 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.688 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.813 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 12906mpt. (fo:block, COMMUNICATIONS) 17:16:09.985 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 12906mpt. (fo:block, COMMUNICATIONS) 17:16:10.423 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm:388 - Line 1 of a paragraph overflows the available area by 14890mpt. (fo:block, SAMPLE_PORT_USD) Please, help me, how I can fix it! Thanks a lot! __ Information from ESET NOD32 Antivirus, version of virus signature database 5184 (20100609) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: Java Heap
On 09.06.2010 16:57, Andrey Skrypnik wrote: I'm using FOP 0.95 i when i try to generate a big file i received: SEVERE: Servlet.service() for servlet meritservus threw exception java.lang.OutOfMemoryError: Java heap space See http://xmlgraphics.apache.org/fop/0.95/running.html#memory J.Pietschmann - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi, I tried to do what Chris told me, and FOP started working, but the warnings did not disappear. Decided to take a deep breath and wait for the new stable FOP version %-| Vincent Hennebert-2 wrote: Best regards, Nancy Hi Nancy, Don’t put the new files in system-wide directories (/usr/share/java, /usr/bin/build). Those directories are managed by Debian administration tools and if you manually modify things there you’re likely to break your system. The ideal way is to create a Debian package containing the Trunk version of FOP, and that will overwrite the official package distributed by Debian. But not everyone can do that, so the usual way is to unzip the new FOP in some of your own local folders, and make sure you call the fop command from that folder (usually by giving the full path like /home/nancy/fop-trunk/fop). There are ways to avoid typing the whole path every time, but this is really getting off-topic for this list. If you don’t know how to do you may want to ask some local Linux guru for help. HTH, Vincent nancy_b wrote: Hi Chris, Thanks for your valuable comments! Do I have to rename the new files with the names of the original ones? Best regards, Nancy cbowditch wrote: nancy_b wrote: Hi dear Andreas! Sorry, you are right.. I just couldn't identify your message among piles of messages I've got. So first of all, thanks a lot for your prompt help! I unzipped fop.jar to /usr/bin/build/ and /usr/share/java (how do I check which is a symlink ?), and xmlgraphics-commons-1.4svn.jar to /usr/share/lib (do I have to rename it to xmlgraphics-commons-1.2.jar I have there?) When taking a new fop.jar you also need to update xmlgraphics-commons.jar as that has also changed and the newer fop.jar depends on the changes in xmlgraphics-commons. Hence the error. then, when trying to check the fop version, I get the following: fop -v Exception in thread main java.lang.NoClassDefFoundError: org/apache/xmlgraphics/util/uri/CommonURIResolver at org.apache.fop.apps.FOURIResolver.init(FOURIResolver.java:56) at org.apache.fop.apps.FopFactory.init(FopFactory.java:150) at org.apache.fop.apps.FopFactory.newInstance(FopFactory.java:172) snip/ Chris - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23942058.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Andreas Delmelle wrote: On 07 Jun 2009, at 12:45, nancy_b wrote: Hi Andreas, Hi Nancy, Could I ask the last question in this long thread please? Why are the Symbol and Zapfdiongbat fonts unavailable in italic/bold version? Hmm... To be honest, I don't know the precise reason. On the other hand, I just played with some other Webdings fonts in OS X TextEdit, and none of them seem to allow formatting the characters in bold/ italic either. What would a user expect as output for a scissor in italic or bold? Main point remains: FOP should probably just silently revert to 'normal' for the style/weight for those font-families. Not sure I agree with you on this point. FOP should not silently revert to normal variants of any Font. A warning should be issued so the user knows there is a mistake in their XSL-FO - albeit a minor one. Thank you a lot in advance for building fop.jar for me. You are so kind! :clap: No problem at all. To tell you the truth, if one has the environment set up correctly, that is just a one-minute job... Thanks, Chris - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi dear Andreas! Sorry, you are right.. I just couldn't identify your message among piles of messages I've got. So first of all, thanks a lot for your prompt help! I unzipped fop.jar to /usr/bin/build/ and /usr/share/java (how do I check which is a symlink ?), and xmlgraphics-commons-1.4svn.jar to /usr/share/lib (do I have to rename it to xmlgraphics-commons-1.2.jar I have there?) then, when trying to check the fop version, I get the following: fop -v Exception in thread main java.lang.NoClassDefFoundError: org/apache/xmlgraphics/util/uri/CommonURIResolver at org.apache.fop.apps.FOURIResolver.init(FOURIResolver.java:56) at org.apache.fop.apps.FopFactory.init(FopFactory.java:150) at org.apache.fop.apps.FopFactory.newInstance(FopFactory.java:172) at org.apache.fop.cli.CommandLineOptions.init(CommandLineOptions.java:115) at org.apache.fop.cli.Main.startFOP(Main.java:157) at org.apache.fop.cli.Main.main(Main.java:205) Caused by: java.lang.ClassNotFoundException: org.apache.xmlgraphics.util.uri.CommonURIResolver at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) Of course, I can't compile either. Please, advise!!! Thanks a lot in advance! Nancy Andreas Delmelle-2 wrote: On 07 Jun 2009, at 14:05, nancy_b wrote: Hi Nancy Looking forward to getting the all new fop.jar.:jumping: You mean you haven't received it? I sent it out last Thursday... By the way, I have two instances of it: /usr/bin/build/fop.jar (where fop is installed) and /usr/share/java/fop.jar Where should I put the new one? That depends from where the current one is run. Can you check whether they are both really the JARs, and one is not simply a symlink to the other? Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23920270.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi Andreas, Thank you a lot for your valuable help!!! I really appreciate that! I decided not to use workarounds, and wait for the next FOP build. I can live with these warnings for a while - the main thing is to understand why they are generated. Could I ask the last question in this long thread please? Why are the Symbol and Zapfdiongbat fonts unavailable in italic/bold version? Thank you a lot in advance for building fop.jar for me. You are so kind! :clap: My best wishes, Nancy Andreas Delmelle-2 wrote: On 04 Jun 2009, at 17:01, nancy_b wrote: Hi Nancy It seems that getting FOP from the trunk is too complicated for me. When is the next binary FOP version due to? Well, it was initially planned for early this year, but we didn't quite get around to it yet. Regarding what you said about fo:block linefeed- treatment=preserve - I have no idea how to translate this into XSL/XML. I admit, this probably requires a significant level of understanding all the Docbook stylesheets' code... Meantime, I did some other tests. Bob Stayton suggested the following workaround for producing special characters: xsl:template match=symb...@role = 'symbolfont'] fo:inline font-family=Symbol xsl:call-template name=inline.charseq/ /fo:inline /xsl:template Personally, as mentioned, I'd make that fo:wrapper instead of fo:inline. fo:inline is really only useful if you need borders or special alignment (sub- or superscript), or if you need margins (which FOP currently does not completely support on inlines anyway). Not that it will have much impact on the result, but the memory consumption should decrease slightly. Every little bit helps there. So I modified it by adding Zapfdingbats before Symbol, and used symbol role = 'symbolfont'#x260E/symbol in my XML. Guess what, it did show the phone symbol, but also converted my math symbol into scissors (rrr). So, I am sick and tired of this -- the only way out is to wait for bugfix in FOP, am I right? I think so. I'll build a fop.jar off today's trunk, and send it to you off-list, so you can try it out and see if that fares better (although I'd rather not see this becoming a standard practice, I'm always willing to make an exception now and then, until we get the automated snapshots operational again) Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23909748.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
On 07 Jun 2009, at 12:45, nancy_b wrote: Hi Nancy, Could I ask the last question in this long thread please? Why are the Symbol and Zapfdiongbat fonts unavailable in italic/bold version? Hmm... To be honest, I don't know the precise reason. On the other hand, I just played with some other Webdings fonts in OS X TextEdit, and none of them seem to allow formatting the characters in bold/ italic either. What would a user expect as output for a scissor in italic or bold? Main point remains: FOP should probably just silently revert to 'normal' for the style/weight for those font-families. Thank you a lot in advance for building fop.jar for me. You are so kind! :clap: No problem at all. To tell you the truth, if one has the environment set up correctly, that is just a one-minute job... Glad to be of help! Later Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Thank you again, dear Andreas!!! Looking forward to getting the all new fop.jar.:jumping: By the way, I have two instances of it: /usr/bin/build/fop.jar (where fop is installed) and /usr/share/java/fop.jar Where should I put the new one? Best regards, Nancy Andreas Delmelle-2 wrote: On 07 Jun 2009, at 12:45, nancy_b wrote: Hi Nancy, Could I ask the last question in this long thread please? Why are the Symbol and Zapfdiongbat fonts unavailable in italic/bold version? Hmm... To be honest, I don't know the precise reason. On the other hand, I just played with some other Webdings fonts in OS X TextEdit, and none of them seem to allow formatting the characters in bold/ italic either. What would a user expect as output for a scissor in italic or bold? Main point remains: FOP should probably just silently revert to 'normal' for the style/weight for those font-families. Thank you a lot in advance for building fop.jar for me. You are so kind! :clap: No problem at all. To tell you the truth, if one has the environment set up correctly, that is just a one-minute job... Glad to be of help! Later Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23910330.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
On 07 Jun 2009, at 14:05, nancy_b wrote: Hi Nancy Looking forward to getting the all new fop.jar.:jumping: You mean you haven't received it? I sent it out last Thursday... By the way, I have two instances of it: /usr/bin/build/fop.jar (where fop is installed) and /usr/share/java/fop.jar Where should I put the new one? That depends from where the current one is run. Can you check whether they are both really the JARs, and one is not simply a symlink to the other? Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi Nancy, nancy_b wrote: Hi Andreas, It seems that getting FOP from the trunk is too complicated for me. When is the next binary FOP version due to? Regarding what you said about fo:block linefeed-treatment=preserve - I have no idea how to translate this into XSL/XML. Meantime, I did some other tests. Bob Stayton suggested the following workaround for producing special characters: xsl:template match=symb...@role = 'symbolfont'] fo:inline font-family=Symbol xsl:call-template name=inline.charseq/ /fo:inline /xsl:template So I modified it by adding Zapfdingbats before Symbol, and used symbol role = 'symbolfont'#x260E/symbol in my XML. Guess what, it did show the phone symbol, but also converted my math symbol into scissors (rrr). So, I am sick and tired of this -- the only way out is to wait for bugfix in FOP, am I right? Well I think you’re almost done actually, Bob’s suggestion was the kind of workaround you were needing. What you probably need is to define two templates, one for ZapfDingbats and one for Symbol. For your telephone you would use symbol role=dingbatfont#x260E;/symbol, for your math character you would use e.g. symbol role=symbolfont#x2211;/symbol. I’ve tried to render a simple DocBook document with FOP 0.95 and to avoid the warnings about missing bold versions of Symbol and ZapfDingbats, you must redefine the body.fontset and title.fontset variables in your customization layer: xsl:variable name=body.fontset select='serif'/ xsl:variable name=title.fontset select='serif'/ I don’t know in which version of the DocBook XSLT stylesheets those variables were introduced though, I’ve got version 1.73.2 installed on my hard drive. If you’re working with an older version the solution may be different. Together with the workarounds above, you should finally be able to get the output you want with FOP 0.95, without annoying warnings. Unless of course you’re putting your telephone and math characters inside an element that must be rendered in bold. Thanks for all your help Nancy Regards, nancy snip/ HTH, Vincent - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi dear Andreas, Thanks for your explanations. I think my version of FOP 0.95 does insert Symbol and Zapfdingbats into the font-family parameter - along with sans-serif. Apparently, my repository points to the trunk. Look: fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; font-family=serif,Symbol,ZapfDingbats font-size=12pt text-align=start line-height=normal font-selection-strategy=character-by-character line-height-shift-adjustment=disregard-shifts language=en ... So, I don't see the reason why the # symbol appears in the PDF doc. It seems that FOP finds the Zapfdingbats font... Regards, Nancy Andreas Delmelle-2 wrote: On 03 Jun 2009, at 15:29, nancy_b wrote: Hi Nancy, Vincent, First of all, thank you a lot for your explanations!!! ...the reason was to make the Jeuclid plug-in work more out of the box... Well, actually, the change mentioned by Vincent is not yet in 0.95. The FOPropertyMapping in that branch still uses sans-serif as an initial value for font-family (see: [1], search for 'font-family') The change in question was committed to Trunk only (over a year ago, see [2]), and the reason was to make font-selection-strategy work on fo:character without requiring any intervention from end-users. If you insert a fo:character with a codepoint that is only available in Symbol, then FOP Trunk will automatically choose that font-family, without requiring the author to explicitly set it. FOP 0.95 indeed still shows the 'missing' glyph '#' as Nancy describes further on. [1] http://svn.apache.org/viewvc/xmlgraphics/fop/branches/fop-0_95/src/java/org/apache/fop/fo/FOPropertyMapping.java?revision=637791 [2] http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java?r1=652673r2=655281diff_format=h So, it seems this change cannot be the cause of the warnings in this case. For 0.95, the only possible explanation is the presence of explicit combinations bold/italic + Symbol/ZapfDingbats. Note that most (if not all) of the font-related properties are inherited, so the weight/style property is very likely inherited from the parent FO or another ancestor. I checked on my system - I don't have the Jeuclid plug-in on my system (should be in /lib directory, right?). Does it come by default with FOP or its a separate utility? It is a separate plugin, and can be downloaded at Sourceforge: http://sourceforge.net/project/showfiles.php?group_id=44862 I also tried customizing the fop conf file: font-triplet name=Symbol style=normal weight=bold/ As Vincent already noted, not sure what the intended effect is. The font-triplet is supposed to be a child of a font-metrics element. See: http://xmlgraphics.apache.org/fop/0.95/fonts.html#register The warnings completely disappear, but when I try to use a Zapfdingbat character in my XML (for example, #x260E; - for a phone icon), # appears instead. Does FOP find Zapfdingbat font at all? If not, why doesn't show the warning? As mentioned above, this means that FOP is using another font for that character, which lacks a glyph for that Unicode codepoint. Since the ZapfDingbats family is not used, no complaints there (yet in 0.95). I can only suggest undoing all the changes above. Apparently, they are causing confusion somewhere. I'm afraid I know very little of Docbook, but based on what you mentioned earlier, maybe it's possible to force the weight/style using xsl:params 'symbol.font.style' and 'symbol.font.weight' (? long shot) If the warnings are really a deal-breaker, then FOP Trunk offers one very easy enhancement to substitute the fully resolved triplets at runtime, and map bold/italic to normal for the Symbol and ZapfDingbats fonts: http://xmlgraphics.apache.org/fop/trunk/fonts.html#substitution Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23865647.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
On 04 Jun 2009, at 10:15, nancy_b wrote: Hi Nancy Thanks for your explanations. I think my version of FOP 0.95 does insert Symbol and Zapfdingbats into the font-family parameter - along with sans-serif. Apparently, my repository points to the trunk. Look: fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; font-family=serif,Symbol,ZapfDingbats font-size=12pt text- align=start line-height=normal font-selection-strategy=character-by-character line-height-shift-adjustment=disregard-shifts language=en ... So, I don't see the reason why the # symbol appears in the PDF doc. It seems that FOP finds the Zapfdingbats font... FOP 0.95 does not yet implement automatic selection of the correct font. In the above sample, 0.95 or earlier will always use only the 'serif' font (the first specified in the list). FOP Trunk should be able to deal with that, as it considers all the specified fonts. You have to make sure that either Symbol or ZapfDingbats is specified as the first font (depending on which character/codepoint you want to render). HTH! Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi Andreas, Thanks for your response! So if I install FOP 0.95 from trunk, will it still issue the warnings? I don't understand what you mean by : ... is specified as the first font (depending on which character/codepoint you want to render. In my XML file, I just specify the code of the Zapfdingbats symbol (in the above example, the phone symbol). Thanks in advance! Nancy Andreas Delmelle-2 wrote: On 04 Jun 2009, at 10:15, nancy_b wrote: Hi Nancy Thanks for your explanations. I think my version of FOP 0.95 does insert Symbol and Zapfdingbats into the font-family parameter - along with sans-serif. Apparently, my repository points to the trunk. Look: fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; font-family=serif,Symbol,ZapfDingbats font-size=12pt text- align=start line-height=normal font-selection-strategy=character-by-character line-height-shift-adjustment=disregard-shifts language=en ... So, I don't see the reason why the # symbol appears in the PDF doc. It seems that FOP finds the Zapfdingbats font... FOP 0.95 does not yet implement automatic selection of the correct font. In the above sample, 0.95 or earlier will always use only the 'serif' font (the first specified in the list). FOP Trunk should be able to deal with that, as it considers all the specified fonts. You have to make sure that either Symbol or ZapfDingbats is specified as the first font (depending on which character/codepoint you want to render). HTH! Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23867952.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
On 04 Jun 2009, at 13:17, nancy_b wrote: Hi Nancy Thanks for your response! So if I install FOP 0.95 from trunk, will it still issue the warnings? Just so we are clear: you either use 0.95 or you use the trunk version. I'm puzzled as to what you mean by 'installing 0.95 from trunk'. You would have to check out the trunk source code with a Subversion client, and use Apache Ant to build it. Then use the resulting fop.jar (and dependencies, too: I think XML Graphics Commons' jar has also been updated in the meantime) /instead of/ the fop.jar that is contained in the 0.95 distribution. For more information on downloading and building FOP trunk, see: http://xmlgraphics.apache.org/fop/download.html#source http://xmlgraphics.apache.org/fop/trunk/compiling.html I don't understand what you mean by : ... is specified as the first font (depending on which character/ codepoint you want to render. In my XML file, I just specify the code of the Zapfdingbats symbol (in the above example, the phone symbol). If you need the phone icon, then for FOP 0.95 or earlier, you would need one of the following: fo:character character=#x260E; font-family=ZapfDingbats font-weight=normal font- style=normal / fo:wrapper font-family=ZapfDingbats font-weight=normal font- style=normal#x260E;/fo:wrapper If you would specify 'font-family=AnyOtherFont,ZapfDingbats', then 0.95 will try only the AnyOtherFont family, as it specified first in the list. HTH! Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: ZapfDingbats font issues [was: FOP 0.95 fails to compile large PDF files - java heap space]
Hi Nancy, There seems to be a lot of confusion around here :-) And my own earlier confusion about which version of FOP is affected by the change of the default value for font-family didn’t help :-| So please reset your memory, and let’s start again from the beginning. Which version of FOP are you currently using? You can get it by running ‘fop -v’ on the command line (the first line of output). Don’t use any FOP configuration file, don’t use any XSLT stylesheet customization, just the plain default. What problem do you run into, if any? Please reduce your source XML file to the strict minimum that still shows the issue, and send us the XSL-FO file resulting from the XSLT transformation. Then we can have a look at it and figure out what’s wrong. Thanks, Vincent nancy_b wrote: Hi Andreas, Thanks for your response! So if I install FOP 0.95 from trunk, will it still issue the warnings? I don't understand what you mean by : ... is specified as the first font (depending on which character/codepoint you want to render. In my XML file, I just specify the code of the Zapfdingbats symbol (in the above example, the phone symbol). Thanks in advance! Nancy Andreas Delmelle-2 wrote: On 04 Jun 2009, at 10:15, nancy_b wrote: Hi Nancy Thanks for your explanations. I think my version of FOP 0.95 does insert Symbol and Zapfdingbats into the font-family parameter - along with sans-serif. Apparently, my repository points to the trunk. Look: fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; font-family=serif,Symbol,ZapfDingbats font-size=12pt text- align=start line-height=normal font-selection-strategy=character-by-character line-height-shift-adjustment=disregard-shifts language=en ... So, I don't see the reason why the # symbol appears in the PDF doc. It seems that FOP finds the Zapfdingbats font... FOP 0.95 does not yet implement automatic selection of the correct font. In the above sample, 0.95 or earlier will always use only the 'serif' font (the first specified in the list). FOP Trunk should be able to deal with that, as it considers all the specified fonts. You have to make sure that either Symbol or ZapfDingbats is specified as the first font (depending on which character/codepoint you want to render). HTH! Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi Andreas, I thought that it's enough to put the ZapfDingBat's hexadecimal code for the symbol in my XML file (#x206E) -and that's it - FOP will understand that it has to pick up the Zapfdingbats font and draw the telephone symbol. That's what I did. After compiling the PDF, I opened the .fo file, and here what I see: fo:block/ â +1 (800) 425 9546 fo:block/ In my params.xsl, I have the following parameter: xsl:param name=symbol.font.familySymbol,ZapfDingbats/xsl:param So you mean that if Symbol is the first font, FOP will pick it up, fail to produce the phone symbol, and won't fall back to ZapfDingbats? Thanks in advance! Nancy If you need the phone icon, then for FOP 0.95 or earlier, you would need one of the following: fo:character character=#x260E; font-family=ZapfDingbats font-weight=normal font- style=normal / fo:wrapper font-family=ZapfDingbats font-weight=normal font- style=normal#x260E;/fo:wrapper ... I thought If you would specify 'font-family=AnyOtherFont,ZapfDingbats', then 0.95 will try only the AnyOtherFont family, as it specified first in the list. Andreas Delmelle-2 wrote: On 04 Jun 2009, at 13:17, nancy_b wrote: Hi Nancy Thanks for your response! So if I install FOP 0.95 from trunk, will it still issue the warnings? Just so we are clear: you either use 0.95 or you use the trunk version. I'm puzzled as to what you mean by 'installing 0.95 from trunk'. You would have to check out the trunk source code with a Subversion client, and use Apache Ant to build it. Then use the resulting fop.jar (and dependencies, too: I think XML Graphics Commons' jar has also been updated in the meantime) /instead of/ the fop.jar that is contained in the 0.95 distribution. For more information on downloading and building FOP trunk, see: http://xmlgraphics.apache.org/fop/download.html#source http://xmlgraphics.apache.org/fop/trunk/compiling.html I don't understand what you mean by : ... is specified as the first font (depending on which character/ codepoint you want to render. In my XML file, I just specify the code of the Zapfdingbats symbol (in the above example, the phone symbol). If you need the phone icon, then for FOP 0.95 or earlier, you would need one of the following: fo:character character=#x260E; font-family=ZapfDingbats font-weight=normal font- style=normal / fo:wrapper font-family=ZapfDingbats font-weight=normal font- style=normal#x260E;/fo:wrapper If you would specify 'font-family=AnyOtherFont,ZapfDingbats', then 0.95 will try only the AnyOtherFont family, as it specified first in the list. HTH! Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23868978.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: ZapfDingbats font issues [was: FOP 0.95 fails to compile large PDF files - java heap space]
Hi Vincent, You are right, I was totally confused. I use an unstable version of Debian, so I thought apt-get install will pick up FOP 0.95 from the unstable (trunk) version of FOP. Now I understand that trunk is for source files only. I do use FOP 0.95. All this long discussion aims at: 1) Getting rid of the font warnings in a proper way :-) 2) Ability to compile a PDF that shows Zapfdingbats symbols, and not # instead. Thank you (and others) for your help and patience! Best regards, Nancy Vincent Hennebert-2 wrote: Hi Nancy, There seems to be a lot of confusion around here :-) And my own earlier confusion about which version of FOP is affected by the change of the default value for font-family didn’t help :-| So please reset your memory, and let’s start again from the beginning. Which version of FOP are you currently using? You can get it by running ‘fop -v’ on the command line (the first line of output). Don’t use any FOP configuration file, don’t use any XSLT stylesheet customization, just the plain default. What problem do you run into, if any? Please reduce your source XML file to the strict minimum that still shows the issue, and send us the XSL-FO file resulting from the XSLT transformation. Then we can have a look at it and figure out what’s wrong. Thanks, Vincent nancy_b wrote: Hi Andreas, Thanks for your response! So if I install FOP 0.95 from trunk, will it still issue the warnings? I don't understand what you mean by : ... is specified as the first font (depending on which character/codepoint you want to render. In my XML file, I just specify the code of the Zapfdingbats symbol (in the above example, the phone symbol). Thanks in advance! Nancy Andreas Delmelle-2 wrote: On 04 Jun 2009, at 10:15, nancy_b wrote: Hi Nancy Thanks for your explanations. I think my version of FOP 0.95 does insert Symbol and Zapfdingbats into the font-family parameter - along with sans-serif. Apparently, my repository points to the trunk. Look: fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; font-family=serif,Symbol,ZapfDingbats font-size=12pt text- align=start line-height=normal font-selection-strategy=character-by-character line-height-shift-adjustment=disregard-shifts language=en ... So, I don't see the reason why the # symbol appears in the PDF doc. It seems that FOP finds the Zapfdingbats font... FOP 0.95 does not yet implement automatic selection of the correct font. In the above sample, 0.95 or earlier will always use only the 'serif' font (the first specified in the list). FOP Trunk should be able to deal with that, as it considers all the specified fonts. You have to make sure that either Symbol or ZapfDingbats is specified as the first font (depending on which character/codepoint you want to render). HTH! Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23869093.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
On 04 Jun 2009, at 14:33, nancy_b wrote: Hi Nancy So you mean that if Symbol is the first font, FOP will pick it up, fail to produce the phone symbol, and won't fall back to ZapfDingbats? For FOP 0.95 or earlier, the answer is unfortunately: Yes. As mentioned, FOP Trunk will effectively use the first font-family that has a glyph for the desired character. In case of complete words, it uses (IIRC) the first font-family that covers all glyphs (or the largest number), so if the phone symbol is embedded in other text, you may still see the missing glyph character (#). As soon as the symbol is separated from the surrounding text by spaces, then ZapfDingbats will be used. (zero-width spaces would be OK too, if you don't want to see a space in the output) Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi Andreas, Thanks for your patience! :-) Taking into account what you said, I did the following test: 1) In my customization area, I added: xsl:param name=symbol.font.familyZapfDingbats/xsl:param 2) Installed ZapfDingbats font on my system and registered it in fop conf: font-triplet name=ZapfDingbats style=normal weight=bold/ font-triplet name=ZapfDingbats style=italic weight=normal/ font-triplet name=ZapfDingbats style=italic weight=bold/ 3) Compiled the PDF (XML file with listitem ZapfDingbats symbol code space phone number /listitem ... And nothing happened - I still get #. I am close to tears ;-(. Best regards, Nancy Andreas Delmelle-2 wrote: On 04 Jun 2009, at 14:33, nancy_b wrote: Hi Nancy So you mean that if Symbol is the first font, FOP will pick it up, fail to produce the phone symbol, and won't fall back to ZapfDingbats? For FOP 0.95 or earlier, the answer is unfortunately: Yes. As mentioned, FOP Trunk will effectively use the first font-family that has a glyph for the desired character. In case of complete words, it uses (IIRC) the first font-family that covers all glyphs (or the largest number), so if the phone symbol is embedded in other text, you may still see the missing glyph character (#). As soon as the symbol is separated from the surrounding text by spaces, then ZapfDingbats will be used. (zero-width spaces would be OK too, if you don't want to see a space in the output) Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23869576.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
nancy_b a écrit : Hi Andreas, I thought that it's enough to put the ZapfDingBat's hexadecimal code for the symbol in my XML file (#x206E) -and that's it - FOP will understand that it has to pick up the Zapfdingbats font and draw the telephone symbol. That's what I did. After compiling the PDF, I opened the .fo file, and here what I see: fo:block/ â +1 (800) 425 9546 fo:block/ If you need the phone icon, then for FOP 0.95 or earlier, you would need one of the following: fo:character character=#x260E; font-family=ZapfDingbats font-weight=normal font- style=normal / fo:wrapper font-family=ZapfDingbats font-weight=normal font- style=normal#x260E;/fo:wrapper ... I thought Hum, #x206E is a deprecated Unicode character. The right Unicode code is #x260E; Pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
On 04 Jun 2009, at 15:07, nancy_b wrote: Hi Nancy Thanks for your patience! :-) No problem. 1) In my customization area, I added: xsl:param name=symbol.font.familyZapfDingbats/xsl:param This should be enough, but IIC, it will also mean that characters that are available in the Symbol font, but not in ZapfDingbats will not be rendered... a FOP-limitation. :-( 2) Installed ZapfDingbats font on my system and registered it in fop conf: font-triplet name=ZapfDingbats style=normal weight=bold/ font-triplet name=ZapfDingbats style=italic weight=normal/ font-triplet name=ZapfDingbats style=italic weight=bold/ This should not be necessary, and may even cause confusion somewhere. ZapfDingbats is a Base-14 font, which FOP supports out-of-the-box. No need to configure custom font-triplets on the FOP-side. HTH! Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi Pascal, I indeed used #x260E; - just made a mistake when writing this message - sorry for that! :-) Regards, nancy Pascal Sancho wrote: nancy_b a écrit : Hi Andreas, I thought that it's enough to put the ZapfDingBat's hexadecimal code for the symbol in my XML file (#x206E) -and that's it - FOP will understand that it has to pick up the Zapfdingbats font and draw the telephone symbol. That's what I did. After compiling the PDF, I opened the .fo file, and here what I see: fo:block/ â +1 (800) 425 9546 fo:block/ If you need the phone icon, then for FOP 0.95 or earlier, you would need one of the following: fo:character character=#x260E; font-family=ZapfDingbats font-weight=normal font- style=normal / fo:wrapper font-family=ZapfDingbats font-weight=normal font- style=normal#x260E;/fo:wrapper ... I thought Hum, #x206E is a deprecated Unicode character. The right Unicode code is #x260E; Pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23869747.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi Andreas, Entering font triplets soothes FOP's pain - no warnings are generated :-) By the way, if you don't specify embed-url, how FOP knows where this file is located? It's not in the standard /fonts folder. I removed the font registration from the conf file and recompiled. Nothing has changed in the output -- still this darn #. Best regards, nancy Andreas Delmelle-2 wrote: On 04 Jun 2009, at 15:07, nancy_b wrote: Hi Nancy Thanks for your patience! :-) No problem. 1) In my customization area, I added: xsl:param name=symbol.font.familyZapfDingbats/xsl:param This should be enough, but IIC, it will also mean that characters that are available in the Symbol font, but not in ZapfDingbats will not be rendered... a FOP-limitation. :-( 2) Installed ZapfDingbats font on my system and registered it in fop conf: font-triplet name=ZapfDingbats style=normal weight=bold/ font-triplet name=ZapfDingbats style=italic weight=normal/ font-triplet name=ZapfDingbats style=italic weight=bold/ This should not be necessary, and may even cause confusion somewhere. ZapfDingbats is a Base-14 font, which FOP supports out-of-the-box. No need to configure custom font-triplets on the FOP-side. HTH! Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23870007.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
On 04 Jun 2009, at 15:30, nancy_b wrote: Hi Nancy Entering font triplets soothes FOP's pain - no warnings are generated :-) By the way, if you don't specify embed-url, how FOP knows where this file is located? It's not in the standard /fonts folder. That's what I'm wondering as well... Can you show the complete font- metrics element? I removed the font registration from the conf file and recompiled. Nothing has changed in the output -- still this darn #. Wait a minute, I just noticed in your earlier post: fo:block/ #x260E; +1 (800) 425 9546 fo:block/ This will simply use the font-family that is specified on the parent fo:block. The symbol should be encapsulated in a fo:wrapper element (or entered as a fo:character) which explicitly resets the font-family to ZapfDingbats. BTW: since the thread started with a question on how to avoid OOMErrors, you may want to consider (if possible) to avoid generating too many of those empty fo:blocks and instead switch to linefeed- treatment=preserve to retain the explicit line-breaks. fo:block linefeed-treatment=preserve#x0A;260E; +1 (800) 425 9546#x0A;/fo:block produces the same output, but is massively more efficient in terms of memory consumption. Empty fo:blocks can still be useful if you want to get creative with space-before/space-after, but if you just need explicit line-breaks, then using something like preserved linefeeds, or Unicode line- or paragraph-breaks (#x0085;, #x2028; or #x2029;) will save heaps of memory. Should work in 0.95. Something similar for fo:inline, which is often used only to switch font-related properties. fo:wrapper does this just as well (since the font-properties are inherited), but are much less wasteful. If you don't need specific alignment-adjust (or borders, or any other non- inherited property), use wrappers instead of inlines. That said, FOP Trunk will have no problem rendering the phone symbol in the original fragment, without requiring any additional intervention. HTH! Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi Andreas, It seems that getting FOP from the trunk is too complicated for me. When is the next binary FOP version due to? Regarding what you said about fo:block linefeed-treatment=preserve - I have no idea how to translate this into XSL/XML. Meantime, I did some other tests. Bob Stayton suggested the following workaround for producing special characters: xsl:template match=symb...@role = 'symbolfont'] fo:inline font-family=Symbol xsl:call-template name=inline.charseq/ /fo:inline /xsl:template So I modified it by adding Zapfdingbats before Symbol, and used symbol role = 'symbolfont'#x260E/symbol in my XML. Guess what, it did show the phone symbol, but also converted my math symbol into scissors (rrr). So, I am sick and tired of this -- the only way out is to wait for bugfix in FOP, am I right? Thanks for all your help Nancy Regards, nancy Andreas Delmelle-2 wrote: On 04 Jun 2009, at 15:30, nancy_b wrote: Hi Nancy Entering font triplets soothes FOP's pain - no warnings are generated :-) By the way, if you don't specify embed-url, how FOP knows where this file is located? It's not in the standard /fonts folder. That's what I'm wondering as well... Can you show the complete font- metrics element? I removed the font registration from the conf file and recompiled. Nothing has changed in the output -- still this darn #. Wait a minute, I just noticed in your earlier post: fo:block/ #x260E; +1 (800) 425 9546 fo:block/ This will simply use the font-family that is specified on the parent fo:block. The symbol should be encapsulated in a fo:wrapper element (or entered as a fo:character) which explicitly resets the font-family to ZapfDingbats. BTW: since the thread started with a question on how to avoid OOMErrors, you may want to consider (if possible) to avoid generating too many of those empty fo:blocks and instead switch to linefeed- treatment=preserve to retain the explicit line-breaks. fo:block linefeed-treatment=preserve#x0A;260E; +1 (800) 425 9546#x0A;/fo:block produces the same output, but is massively more efficient in terms of memory consumption. Empty fo:blocks can still be useful if you want to get creative with space-before/space-after, but if you just need explicit line-breaks, then using something like preserved linefeeds, or Unicode line- or paragraph-breaks (#x0085;, #x2028; or #x2029;) will save heaps of memory. Should work in 0.95. Something similar for fo:inline, which is often used only to switch font-related properties. fo:wrapper does this just as well (since the font-properties are inherited), but are much less wasteful. If you don't need specific alignment-adjust (or borders, or any other non- inherited property), use wrappers instead of inlines. That said, FOP Trunk will have no problem rendering the phone symbol in the original fragment, without requiring any additional intervention. HTH! Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23871704.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
On 04 Jun 2009, at 17:01, nancy_b wrote: Hi Nancy It seems that getting FOP from the trunk is too complicated for me. When is the next binary FOP version due to? Well, it was initially planned for early this year, but we didn't quite get around to it yet. Regarding what you said about fo:block linefeed- treatment=preserve - I have no idea how to translate this into XSL/XML. I admit, this probably requires a significant level of understanding all the Docbook stylesheets' code... Meantime, I did some other tests. Bob Stayton suggested the following workaround for producing special characters: xsl:template match=symb...@role = 'symbolfont'] fo:inline font-family=Symbol xsl:call-template name=inline.charseq/ /fo:inline /xsl:template Personally, as mentioned, I'd make that fo:wrapper instead of fo:inline. fo:inline is really only useful if you need borders or special alignment (sub- or superscript), or if you need margins (which FOP currently does not completely support on inlines anyway). Not that it will have much impact on the result, but the memory consumption should decrease slightly. Every little bit helps there. So I modified it by adding Zapfdingbats before Symbol, and used symbol role = 'symbolfont'#x260E/symbol in my XML. Guess what, it did show the phone symbol, but also converted my math symbol into scissors (rrr). So, I am sick and tired of this -- the only way out is to wait for bugfix in FOP, am I right? I think so. I'll build a fop.jar off today's trunk, and send it to you off-list, so you can try it out and see if that fares better (although I'd rather not see this becoming a standard practice, I'm always willing to make an exception now and then, until we get the automated snapshots operational again) Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi, Thanks a lot for suggestions. It seems that I have increased JAVA heap space, by specifying -Xmx1000m (I have 2Gb) , although I am not sure how much I should really allocate for running compilation of large docs. The question that remained unclear is that while FOP 0.94 doesn't complain on the fonts, FOP 0.95 generates the following error message: WARNING: Font 'Symbol,normal,700' not found. Substituting with 'Symbol,normal,400'. Jun 2, 2009 2:14:25 PM org.apache.fop.fonts.FontInfo notifyFontReplacement WARNING: Font 'ZapfDingbats,normal,700' not found. Substituting with 'ZapfDingbats,normal,400'. Jun 2, 2009 2:14:31 PM org.apache.fop.hyphenation.Hyphenator getHyphenationTree I don't understand why FOP 0.94 did not have such a problem, while FOP 0.95 does. I checked on my Linux Debian system - it does have the Symbol font in /usr/share/cups/fonts/. For Zapfdinbats I found the following file: /usr/lib/openoffice/share/psprint/fontmetric/ZapfDingbats.afm. I think that's just a metric file for the font. So, I put the following in FOP's conf file: font-triplet name=Symbol style=normal weight=700/ font-triplet name=ZapfDingbats style=normal weight=700/ font-triplet name=ZapfDingbats style=italic weight=700/ font-triplet name=ZapfDingbats style=italic weight=400/ And guess what, the warning disappeared. The question is whether it really solved the problem - whether FOP really identified these fonts. For example, I don't have ZapfDingbats font - just its metric?! Thanks for your in put in advance!!! Regards, Nancy Pascal Sancho wrote: nancy_b a écrit : Hi folks, I decided to move to FOP 0.95 (previously used FOP 0.94). When compiling a large PDF doc (more than 200 pages) the following error occurs: FOP Exception in thread main java.lang.OutOfMemoryError: Java heap space What is really frustrating and annoying is that FOP 0.94 did not have such a problem. Could you please explain why the new FOP version has this problem. We usually expect improvements in the newer versions... ;-( Thanks in advance! Nancy Hi, There is a lot of improvment in FOP 0.95 that can explain a /light/ increase of memory consumption (new image support, better font hanfling, etc.) Perhaps the memory allocated to FOP was /just/ enough with 0.94 version, but not with 0.95 version. You should 1st increase the max memory allocation to the JVM. Also check this link: http://xmlgraphics.apache.org/fop/0.95/running.html#memory. Pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23847701.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
nancy_b a écrit : Hi, Thanks a lot for suggestions. It seems that I have increased JAVA heap space, by specifying -Xmx1000m (I have 2Gb) , although I am not sure how much I should really allocate for running compilation of large docs. The question that remained unclear is that while FOP 0.94 doesn't complain on the fonts, FOP 0.95 generates the following error message: WARNING: Font 'Symbol,normal,700' not found. Substituting with 'Symbol,normal,400'. Jun 2, 2009 2:14:25 PM org.apache.fop.fonts.FontInfo notifyFontReplacement WARNING: Font 'ZapfDingbats,normal,700' not found. Substituting with 'ZapfDingbats,normal,400'. These 2 fonts only exist in normal form. Neither bold nor italic. You should check that in your FO fileand *force* font-weight property to normal (or 400, witch is equivalent). Jun 2, 2009 2:14:31 PM org.apache.fop.hyphenation.Hyphenator getHyphenationTree I don't understand why FOP 0.94 did not have such a problem, while FOP 0.95 does. I checked on my Linux Debian system - it does have the Symbol font in /usr/share/cups/fonts/. For Zapfdinbats I found the following file: /usr/lib/openoffice/share/psprint/fontmetric/ZapfDingbats.afm. I think that's just a metric file for the font. So, I put the following in FOP's conf file: font-triplet name=Symbol style=normal weight=700/ font-triplet name=ZapfDingbats style=normal weight=700/ font-triplet name=ZapfDingbats style=italic weight=700/ font-triplet name=ZapfDingbats style=italic weight=400/ And guess what, the warning disappeared. The question is whether it really solved the problem - whether FOP really identified these fonts. For example, I don't have ZapfDingbats font - just its metric?! Thanks for your in put in advance!!! Regards, Nancy Pascal Sancho wrote: nancy_b a écrit : Hi folks, I decided to move to FOP 0.95 (previously used FOP 0.94). When compiling a large PDF doc (more than 200 pages) the following error occurs: FOP Exception in thread main java.lang.OutOfMemoryError: Java heap space What is really frustrating and annoying is that FOP 0.94 did not have such a problem. Could you please explain why the new FOP version has this problem. We usually expect improvements in the newer versions... ;-( Thanks in advance! Nancy Hi, There is a lot of improvment in FOP 0.95 that can explain a /light/ increase of memory consumption (new image support, better font hanfling, etc.) Perhaps the memory allocated to FOP was /just/ enough with 0.94 version, but not with 0.95 version. You should 1st increase the max memory allocation to the JVM. Also check this link: http://xmlgraphics.apache.org/fop/0.95/running.html#memory. Pascal Pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Thanks for suggestions! Kindaian wrote: In my case, i had to change it to the max that the machine would accept... somewhere around 1024m... [but it was on windows and on a 32bit environment... on 64 bits - both os and java - this issues are largelly overcome by the ability to address much more] ;) On 02-06-2009 16:23, Remko Tronçon wrote: thanks for your suggestions. I am using Debian Linux, so I don't have FOP.BAT on my system. Do you have any ideas where I should enter it on Linux? Did you install fop through apt-get install? If so: without having tried this myself, but by looking at the Debian package, perhaps the following could work: export JAVA_ARGS=-Xmx256m If you invoke 'fop' from the shell where you did the 'export' command, I think java will pick up the parameters. If you don't use Debian's fop, I think export FOP_OPTS=-Xmx256m should do the trick. cheers, Remko - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23848443.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi Nancy, nancy_b wrote: Hi, Thanks a lot for suggestions. It seems that I have increased JAVA heap space, by specifying -Xmx1000m (I have 2Gb) , although I am not sure how much I should really allocate for running compilation of large docs. If that works with -Xmx1000m, then go for it. If for some reason you want to use as few memory as possible, then gradually increase the value of -Xmx until the OutOfMemoryError disappears. But you probably don’t want/need to bother so much. The question that remained unclear is that while FOP 0.94 doesn't complain on the fonts, FOP 0.95 generates the following error message: A change was made in FOP 0.95 about the default value of the font-family property. Until 0.94 that was sans-serif, in 0.95 it was changed to sans-serif,Symbol,ZapfDingats. IIRC the reason was to make the Jeuclid plug-in work more out of the box, but it has the unfortunate side effect of issuing the warnings below as soon as you use bold text. There is an open bug about that: https://issues.apache.org/bugzilla/show_bug.cgi?id=47279 The workaround is to explicitly define the font-family property, and not rely on the default value provided by FOP (this is usually done by setting it on the fo:root or fo:page-sequence elements). WARNING: Font 'Symbol,normal,700' not found. Substituting with 'Symbol,normal,400'. Jun 2, 2009 2:14:25 PM org.apache.fop.fonts.FontInfo notifyFontReplacement WARNING: Font 'ZapfDingbats,normal,700' not found. Substituting with 'ZapfDingbats,normal,400'. Jun 2, 2009 2:14:31 PM org.apache.fop.hyphenation.Hyphenator getHyphenationTree I don't understand why FOP 0.94 did not have such a problem, while FOP 0.95 does. I checked on my Linux Debian system - it does have the Symbol font in /usr/share/cups/fonts/. For Zapfdinbats I found the following file: /usr/lib/openoffice/share/psprint/fontmetric/ZapfDingbats.afm. I think that's just a metric file for the font. So, I put the following in FOP's conf file: font-triplet name=Symbol style=normal weight=700/ font-triplet name=ZapfDingbats style=normal weight=700/ font-triplet name=ZapfDingbats style=italic weight=700/ font-triplet name=ZapfDingbats style=italic weight=400/ And guess what, the warning disappeared. The question is whether it really solved the problem - whether FOP really identified these fonts. For example, I don't have ZapfDingbats font - just its metric?! You must have put those font-triplet elements inside a font element, haven’t you? A font-triplet element is not allowed elsewhere. FWIW, the gsfonts package contains clones of the Symbol and ZapfDingbats fonts, they can be found in the /usr/share/fonts/type1/gsfonts/ directory, under the names s05l.* and d05l.* (obvious names, isn’t it ;-) ). But bold/italic versions aren’t available. If you do something like the following, which I suspect is what you meant with your font triplets above: font embed-url=s05l.pfb font-triplet name=Symbol style=normal weight=bold/ /font then you effectively use the normal Symbol as a replacement for the bold one (the text won’t appear in bold!). All that said, stick to the advice above and explicitly define the font-family property instead, and you should get rid of those warnings. Thanks for your in put in advance!!! Regards, Nancy snip/ HTH, Vincent - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi dear Vincent! First of all, thank you a lot for your explanations!!! ...the reason was to make the Jeuclid plug-in work more out of the box... I checked on my system - I don't have the Jeuclid plug-in on my system (should be in /lib directory, right?). Does it come by default with FOP or its a separate utility? ...The workaround is to explicitly define the font-family property, and not rely on the default value provided by FOP (this is usually done by setting it on the fo:root or fo:page-sequence elements) I tried the following in my stylesheet: xsl:attribute-set name=root.properties xsl:attribute name=font-family xsl:value-of select=sans-serif/ /xsl:attribute /xsl:attribute-set it did change the font-family in fo:root but warnings did not disappear. I don't know how to customize fo:page-sequence elements. Please, advise! I also tried customizing the fop conf file: font-triplet name=Symbol style=normal weight=bold/ font-triplet name=ZapfDingbats style=normal weight=700/ font-triplet name=ZapfDingbats style=italic weight=700/ font-triplet name=ZapfDingbats style=italic weight=400/ The warnings completely disappear, but when I try to use a Zapfdingbat character in my XML (for example, #x260E; - for a phone icon), # appears instead. Does FOP find Zapfdingbat font at all? If not, why doesn't show the warning? Thanks a lot in advance! nancy Vincent Hennebert-2 wrote: Hi Nancy, nancy_b wrote: Hi, Thanks a lot for suggestions. It seems that I have increased JAVA heap space, by specifying -Xmx1000m (I have 2Gb) , although I am not sure how much I should really allocate for running compilation of large docs. If that works with -Xmx1000m, then go for it. If for some reason you want to use as few memory as possible, then gradually increase the value of -Xmx until the OutOfMemoryError disappears. But you probably don’t want/need to bother so much. The question that remained unclear is that while FOP 0.94 doesn't complain on the fonts, FOP 0.95 generates the following error message: A change was made in FOP 0.95 about the default value of the font-family property. Until 0.94 that was sans-serif, in 0.95 it was changed to sans-serif,Symbol,ZapfDingats. IIRC the reason was to make the Jeuclid plug-in work more out of the box, but it has the unfortunate side effect of issuing the warnings below as soon as you use bold text. There is an open bug about that: https://issues.apache.org/bugzilla/show_bug.cgi?id=47279 The workaround is to explicitly define the font-family property, and not rely on the default value provided by FOP (this is usually done by setting it on the fo:root or fo:page-sequence elements). WARNING: Font 'Symbol,normal,700' not found. Substituting with 'Symbol,normal,400'. Jun 2, 2009 2:14:25 PM org.apache.fop.fonts.FontInfo notifyFontReplacement WARNING: Font 'ZapfDingbats,normal,700' not found. Substituting with 'ZapfDingbats,normal,400'. Jun 2, 2009 2:14:31 PM org.apache.fop.hyphenation.Hyphenator getHyphenationTree I don't understand why FOP 0.94 did not have such a problem, while FOP 0.95 does. I checked on my Linux Debian system - it does have the Symbol font in /usr/share/cups/fonts/. For Zapfdinbats I found the following file: /usr/lib/openoffice/share/psprint/fontmetric/ZapfDingbats.afm. I think that's just a metric file for the font. So, I put the following in FOP's conf file: font-triplet name=Symbol style=normal weight=700/ font-triplet name=ZapfDingbats style=normal weight=700/ font-triplet name=ZapfDingbats style=italic weight=700/ font-triplet name=ZapfDingbats style=italic weight=400/ And guess what, the warning disappeared. The question is whether it really solved the problem - whether FOP really identified these fonts. For example, I don't have ZapfDingbats font - just its metric?! You must have put those font-triplet elements inside a font element, haven’t you? A font-triplet element is not allowed elsewhere. FWIW, the gsfonts package contains clones of the Symbol and ZapfDingbats fonts, they can be found in the /usr/share/fonts/type1/gsfonts/ directory, under the names s05l.* and d05l.* (obvious names, isn’t it ;-) ). But bold/italic versions aren’t available. If you do something like the following, which I suspect is what you meant with your font triplets above: font-triplet name=Symbol style=normal weight=bold/ then you effectively use the normal Symbol as a replacement for the bold one (the text won’t appear in bold!). All that said, stick to the advice above and explicitly define the font-family property instead, and you should get rid of those warnings. Thanks for your in put in advance!!! Regards, Nancy
Re: FOP 0.95 fails to compile large PDF files - java heap space
On 03 Jun 2009, at 15:29, nancy_b wrote: Hi Nancy, Vincent, First of all, thank you a lot for your explanations!!! ...the reason was to make the Jeuclid plug-in work more out of the box... Well, actually, the change mentioned by Vincent is not yet in 0.95. The FOPropertyMapping in that branch still uses sans-serif as an initial value for font-family (see: [1], search for 'font-family') The change in question was committed to Trunk only (over a year ago, see [2]), and the reason was to make font-selection-strategy work on fo:character without requiring any intervention from end-users. If you insert a fo:character with a codepoint that is only available in Symbol, then FOP Trunk will automatically choose that font-family, without requiring the author to explicitly set it. FOP 0.95 indeed still shows the 'missing' glyph '#' as Nancy describes further on. [1] http://svn.apache.org/viewvc/xmlgraphics/fop/branches/fop-0_95/src/java/org/apache/fop/fo/FOPropertyMapping.java?revision=637791 [2] http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java?r1=652673r2=655281diff_format=h So, it seems this change cannot be the cause of the warnings in this case. For 0.95, the only possible explanation is the presence of explicit combinations bold/italic + Symbol/ZapfDingbats. Note that most (if not all) of the font-related properties are inherited, so the weight/style property is very likely inherited from the parent FO or another ancestor. I checked on my system - I don't have the Jeuclid plug-in on my system (should be in /lib directory, right?). Does it come by default with FOP or its a separate utility? It is a separate plugin, and can be downloaded at Sourceforge: http://sourceforge.net/project/showfiles.php?group_id=44862 I also tried customizing the fop conf file: font-triplet name=Symbol style=normal weight=bold/ As Vincent already noted, not sure what the intended effect is. The font-triplet is supposed to be a child of a font-metrics element. See: http://xmlgraphics.apache.org/fop/0.95/fonts.html#register The warnings completely disappear, but when I try to use a Zapfdingbat character in my XML (for example, #x260E; - for a phone icon), # appears instead. Does FOP find Zapfdingbat font at all? If not, why doesn't show the warning? As mentioned above, this means that FOP is using another font for that character, which lacks a glyph for that Unicode codepoint. Since the ZapfDingbats family is not used, no complaints there (yet in 0.95). I can only suggest undoing all the changes above. Apparently, they are causing confusion somewhere. I'm afraid I know very little of Docbook, but based on what you mentioned earlier, maybe it's possible to force the weight/style using xsl:params 'symbol.font.style' and 'symbol.font.weight' (? long shot) If the warnings are really a deal-breaker, then FOP Trunk offers one very easy enhancement to substitute the fully resolved triplets at runtime, and map bold/italic to normal for the Symbol and ZapfDingbats fonts: http://xmlgraphics.apache.org/fop/trunk/fonts.html#substitution Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
nancy_b a écrit : Hi folks, I decided to move to FOP 0.95 (previously used FOP 0.94). When compiling a large PDF doc (more than 200 pages) the following error occurs: FOP Exception in thread main java.lang.OutOfMemoryError: Java heap space What is really frustrating and annoying is that FOP 0.94 did not have such a problem. Could you please explain why the new FOP version has this problem. We usually expect improvements in the newer versions... ;-( Thanks in advance! Nancy Hi, There is a lot of improvment in FOP 0.95 that can explain a /light/ increase of memory consumption (new image support, better font hanfling, etc.) Perhaps the memory allocated to FOP was /just/ enough with 0.94 version, but not with 0.95 version. You should 1st increase the max memory allocation to the JVM. Also check this link: http://xmlgraphics.apache.org/fop/0.95/running.html#memory. Pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi dear Pascal, Thank you for your response. I can't see any improvement in handling fonts. For example, while FOP 0.94 hasn't complained, FOP 0.95 generates the following error message: WARNING: Font 'Symbol,normal,700' not found. Substituting with 'Symbol,normal,400'. Jun 2, 2009 2:14:25 PM org.apache.fop.fonts.FontInfo notifyFontReplacement WARNING: Font 'ZapfDingbats,normal,700' not found. Substituting with 'ZapfDingbats,normal,400'. Jun 2, 2009 2:14:31 PM org.apache.fop.hyphenation.Hyphenator getHyphenationTree I checked with my stylesheets, and I don't see any place where I explicitly told the compiler to use these fonts in my customization layer. After a lot of investigation, I changed the following default parameter: xsl:param name=symbol.font.familySymbol,ZapfDingbats/xsl:param to xsl:param name=symbol.font.familyHelvetica/xsl:param and this caused these messages to disappear. However, I am not sure that it was a correct workaround. Why did FOP 0.94 not complain about these fonts? Moreover, it's still unclear to me how I should increase JAVA heap size using the Xmx argument? Where should I enter it? Thanks a lot in advance! Nancy Pascal Sancho wrote: nancy_b a écrit : Hi folks, I decided to move to FOP 0.95 (previously used FOP 0.94). When compiling a large PDF doc (more than 200 pages) the following error occurs: FOP Exception in thread main java.lang.OutOfMemoryError: Java heap space What is really frustrating and annoying is that FOP 0.94 did not have such a problem. Could you please explain why the new FOP version has this problem. We usually expect improvements in the newer versions... ;-( Thanks in advance! Nancy Hi, There is a lot of improvment in FOP 0.95 that can explain a /light/ increase of memory consumption (new image support, better font hanfling, etc.) Perhaps the memory allocated to FOP was /just/ enough with 0.94 version, but not with 0.95 version. You should 1st increase the max memory allocation to the JVM. Also check this link: http://xmlgraphics.apache.org/fop/0.95/running.html#memory. Pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23830728.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
nancy_b a écrit : Hi dear Pascal, Thank you for your response. I can't see any improvement in handling fonts. See: http://xmlgraphics.apache.org/fop/0.95/changes_0.95beta.html#Changes+to+the+Font+Subsystem http://xmlgraphics.apache.org/fop/0.95/changes_0.95.html#Changes+to+the+Font+Subsystem For example, while FOP 0.94 hasn't complained, FOP 0.95 generates the following error message: WARNING: Font 'Symbol,normal,700' not found. Substituting with 'Symbol,normal,400'. Jun 2, 2009 2:14:25 PM org.apache.fop.fonts.FontInfo notifyFontReplacement WARNING: Font 'ZapfDingbats,normal,700' not found. Substituting with 'ZapfDingbats,normal,400'. Jun 2, 2009 2:14:31 PM org.apache.fop.hyphenation.Hyphenator getHyphenationTree I checked with my stylesheets, and I don't see any place where I explicitly told the compiler to use these fonts in my customization layer. After a lot of investigation, I changed the following default parameter: xsl:param name=symbol.font.familySymbol,ZapfDingbats/xsl:param to xsl:param name=symbol.font.familyHelvetica/xsl:param and this caused these messages to disappear. However, I am not sure that it was a correct workaround. Why did FOP 0.94 not complain about these fonts? Moreover, it's still unclear to me how I should increase JAVA heap size using the Xmx argument? Where should I enter it? Depending on how you invoke FOP: Command Line under Windows: In FOP.BAT, find the line [set JAVAOPTS=-Denv.windir=%WINDIR%] and add the parameter like this: [set JAVAOPTS=-Denv.windir=%WINDIR% -Xmx256m] Where 256m is for 256Mb FYI, xmx defaults to 64m For embedded FOP, this depends on how the application is invoked. For example, with Tomcat, you can do that from the monitor tool, tab [Java], field [Max Memory Pool] Thanks a lot in advance! Nancy Pascal Sancho wrote: nancy_b a écrit : Hi folks, I decided to move to FOP 0.95 (previously used FOP 0.94). When compiling a large PDF doc (more than 200 pages) the following error occurs: FOP Exception in thread main java.lang.OutOfMemoryError: Java heap space What is really frustrating and annoying is that FOP 0.94 did not have such a problem. Could you please explain why the new FOP version has this problem. We usually expect improvements in the newer versions... ;-( Thanks in advance! Nancy Hi, There is a lot of improvment in FOP 0.95 that can explain a /light/ increase of memory consumption (new image support, better font hanfling, etc.) Perhaps the memory allocated to FOP was /just/ enough with 0.94 version, but not with 0.95 version. You should 1st increase the max memory allocation to the JVM. Also check this link: http://xmlgraphics.apache.org/fop/0.95/running.html#memory. Pascal HTH, Pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi Pascal, thanks for your suggestions. I am using Debian Linux, so I don't have FOP.BAT on my system. Do you have any ideas where I should enter it on Linux? Thanks in advance! Nancy Pascal Sancho wrote: nancy_b a écrit : Hi dear Pascal, Thank you for your response. I can't see any improvement in handling fonts. See: http://xmlgraphics.apache.org/fop/0.95/changes_0.95beta.html#Changes+to+the+Font+Subsystem http://xmlgraphics.apache.org/fop/0.95/changes_0.95.html#Changes+to+the+Font+Subsystem For example, while FOP 0.94 hasn't complained, FOP 0.95 generates the following error message: WARNING: Font 'Symbol,normal,700' not found. Substituting with 'Symbol,normal,400'. Jun 2, 2009 2:14:25 PM org.apache.fop.fonts.FontInfo notifyFontReplacement WARNING: Font 'ZapfDingbats,normal,700' not found. Substituting with 'ZapfDingbats,normal,400'. Jun 2, 2009 2:14:31 PM org.apache.fop.hyphenation.Hyphenator getHyphenationTree I checked with my stylesheets, and I don't see any place where I explicitly told the compiler to use these fonts in my customization layer. After a lot of investigation, I changed the following default parameter: xsl:param name=symbol.font.familySymbol,ZapfDingbats/xsl:param to xsl:param name=symbol.font.familyHelvetica/xsl:param and this caused these messages to disappear. However, I am not sure that it was a correct workaround. Why did FOP 0.94 not complain about these fonts? Moreover, it's still unclear to me how I should increase JAVA heap size using the Xmx argument? Where should I enter it? Depending on how you invoke FOP: Command Line under Windows: In FOP.BAT, find the line [set JAVAOPTS=-Denv.windir=%WINDIR%] and add the parameter like this: [set JAVAOPTS=-Denv.windir=%WINDIR% -Xmx256m] Where 256m is for 256Mb FYI, xmx defaults to 64m For embedded FOP, this depends on how the application is invoked. For example, with Tomcat, you can do that from the monitor tool, tab [Java], field [Max Memory Pool] Thanks a lot in advance! Nancy Pascal Sancho wrote: nancy_b a écrit : Hi folks, I decided to move to FOP 0.95 (previously used FOP 0.94). When compiling a large PDF doc (more than 200 pages) the following error occurs: FOP Exception in thread main java.lang.OutOfMemoryError: Java heap space What is really frustrating and annoying is that FOP 0.94 did not have such a problem. Could you please explain why the new FOP version has this problem. We usually expect improvements in the newer versions... ;-( Thanks in advance! Nancy Hi, There is a lot of improvment in FOP 0.95 that can explain a /light/ increase of memory consumption (new image support, better font hanfling, etc.) Perhaps the memory allocated to FOP was /just/ enough with 0.94 version, but not with 0.95 version. You should 1st increase the max memory allocation to the JVM. Also check this link: http://xmlgraphics.apache.org/fop/0.95/running.html#memory. Pascal HTH, Pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23832365.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi Nancy, I decided to move to FOP 0.95 (previously used FOP 0.94). When compiling a large PDF doc (more than 200 pages) the following error occurs: FOP Exception in thread main java.lang.OutOfMemoryError: Java heap space Is the content of your PDF wrapped in one single fo:page-sequence (in FO)? Because this was a problem for me when exporting 1700+ pages. If this is the case try to split it into more page-sequences. As mentioned by other repliers, you should first try to increase the memory for the VM (-Xmx value). I am using about 1024m. -- Cheers, Tobias K15t Software UG (haftungsbeschränkt), http://www.k15t.com Rosenbergstr. 58, 70176 Stuttgart, GERMANY Registration: Stuttgart HRB 729752, VAT ID: DE264753756 Geschäftsführer (CEO): Klaus-Dieter Krüger - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
nancy_b a écrit : Hi Pascal, thanks for your suggestions. I am using Debian Linux, so I don't have FOP.BAT on my system. Do you have any ideas where I should enter it on Linux? Thanks in advance! Nancy Unfortunately, I'm not familiarized with shell script under Linux. I just know that the bash script file is fop. Someone else that usually works on Linux could help you. Vincent? Pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
Hi Tobias, Thanks for your valuable input. How can I split the file? Yes, I create a .fo file first. Thanks in advance! Nancy Tobias Anstett [k15t.com] wrote: Hi Nancy, I decided to move to FOP 0.95 (previously used FOP 0.94). When compiling a large PDF doc (more than 200 pages) the following error occurs: FOP Exception in thread main java.lang.OutOfMemoryError: Java heap space Is the content of your PDF wrapped in one single fo:page-sequence (in FO)? Because this was a problem for me when exporting 1700+ pages. If this is the case try to split it into more page-sequences. As mentioned by other repliers, you should first try to increase the memory for the VM (-Xmx value). I am using about 1024m. -- Cheers, Tobias K15t Software UG (haftungsbeschränkt), http://www.k15t.com Rosenbergstr. 58, 70176 Stuttgart, GERMANY Registration: Stuttgart HRB 729752, VAT ID: DE264753756 Geschäftsführer (CEO): Klaus-Dieter Krüger - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23834826.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
thanks for your suggestions. I am using Debian Linux, so I don't have FOP.BAT on my system. Do you have any ideas where I should enter it on Linux? Did you install fop through apt-get install? If so: without having tried this myself, but by looking at the Debian package, perhaps the following could work: export JAVA_ARGS=-Xmx256m If you invoke 'fop' from the shell where you did the 'export' command, I think java will pick up the parameters. If you don't use Debian's fop, I think export FOP_OPTS=-Xmx256m should do the trick. cheers, Remko - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 0.95 fails to compile large PDF files - java heap space
In my case, i had to change it to the max that the machine would accept... somewhere around 1024m... [but it was on windows and on a 32bit environment... on 64 bits - both os and java - this issues are largelly overcome by the ability to address much more] ;) On 02-06-2009 16:23, Remko Tronçon wrote: thanks for your suggestions. I am using Debian Linux, so I don't have FOP.BAT on my system. Do you have any ideas where I should enter it on Linux? Did you install fop through apt-get install? If so: without having tried this myself, but by looking at the Debian package, perhaps the following could work: export JAVA_ARGS=-Xmx256m If you invoke 'fop' from the shell where you did the 'export' command, I think java will pick up the parameters. If you don't use Debian's fop, I think export FOP_OPTS=-Xmx256m should do the trick. cheers, Remko - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
FOP 0.95 fails to compile large PDF files - java heap space
Hi folks, I decided to move to FOP 0.95 (previously used FOP 0.94). When compiling a large PDF doc (more than 200 pages) the following error occurs: FOP Exception in thread main java.lang.OutOfMemoryError: Java heap space What is really frustrating and annoying is that FOP 0.94 did not have such a problem. Could you please explain why the new FOP version has this problem. We usually expect improvements in the newer versions... ;-( Thanks in advance! Nancy -- View this message in context: http://www.nabble.com/FOP-0.95-fails-to-compile-large-PDF-files---java-heap-space-tp23816647p23816647.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Java heap overflow error - unknown reason
We have this environment setting: set FOP_OPTS=-Xmx999m %FOP_OPTS% Then we run the fop command line. To post the fo file I will need to replace the text with gibberish since it is sensitive material. I will attempt to upload it later today. David Kelly Jeremias Maerki-2 wrote: Are you actually giving FOP a little memory to play with? I mean a little more than the 64MB allocated by default? FOP is still a bit memory-intensive, but 100 pages (per page-sequence) should easily be handled with less than 512MB. If you can, post a link to an FO file. That would allow us to do some profiling to see why this happens (if my very obvious tip above doesn't apply). Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Java-heap-overflow-error---unknown-reason-tp18929472p18961914.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java heap overflow error - unknown reason
Hmm - I see now that although the environment variable I mentioned earlier had been set, that variable was not placed on the fop command line. I have corrected the problem and it now runs fine. My apologies for the misdirection, and thank you for the hint. Regards, David Kelly Are you actually giving FOP a little memory to play with? I mean a little more than the 64MB allocated by default? FOP is still a bit memory-intensive, but 100 pages (per page-sequence) should easily be handled with less than 512MB. If you can, post a link to an FO file. That would allow us to do some profiling to see why this happens (if my very obvious tip above doesn't apply). -- View this message in context: http://www.nabble.com/Java-heap-overflow-error---unknown-reason-tp18929472p18962257.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java heap overflow error - unknown reason
Nevertheless, if you can post the fo with gibberish it would be useful for profiling purposes... (if sensitive, send it directly to the dev team and not to the list). There is always a lack of real world examples! And real world is always giving us surprises. ;) On Wed, Aug 13, 2008 at 1:40 PM, DavidJKelly [EMAIL PROTECTED] wrote: Hmm - I see now that although the environment variable I mentioned earlier had been set, that variable was not placed on the fop command line. I have corrected the problem and it now runs fine. My apologies for the misdirection, and thank you for the hint. Regards, David Kelly Are you actually giving FOP a little memory to play with? I mean a little more than the 64MB allocated by default? FOP is still a bit memory-intensive, but 100 pages (per page-sequence) should easily be handled with less than 512MB. If you can, post a link to an FO file. That would allow us to do some profiling to see why this happens (if my very obvious tip above doesn't apply). -- View this message in context: http://www.nabble.com/Java-heap-overflow-error---unknown-reason-tp18929472p18962257.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java heap overflow error - unknown reason
Andreas, Most of the book was in fact in a single page sequence. I attempted the three fixes you suggested, but with no luck. The FO is now in page sequences less than 100 pages each, and all fo:inlines are now fo:wrappers. I have also removed all keep-together and keep-with attributes. At risk of repetition, here is the error I get: WARNING: Line 2 of a paragraph overflows the available area by 400mpt. (fo:block , location: 46211/114) Exception in thread main java.lang.OutOfMemoryError: Java heap space at org.apache.fop.layoutmgr.inline.TextLayoutManager.createTextArea(Text LayoutManager.java:408) at org.apache.fop.layoutmgr.inline.TextLayoutManager.addAreas(TextLayout Manager.java:361) at org.apache.fop.layoutmgr.inline.LineLayoutManager.addInlineArea(LineL ayoutManager.java:1716) at org.apache.fop.layoutmgr.inline.LineLayoutManager.addAreas(LineLayout Manager.java:1568) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.AreaAdditionUtil.addAreas(AreaAdditionUtil.j ava:121) at org.apache.fop.layoutmgr.FlowLayoutManager.addAreas(FlowLayoutManager .java:305) at org.apache.fop.layoutmgr.PageBreaker.addAreas(PageBreaker.java:241) at org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.jav a:508) at org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.jav a:371) at org.apache.fop.layoutmgr.PageBreaker.doPhase3(PageBreaker.java:262) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.jav a:346) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.jav a:264) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(Pag eSequenceLayoutManager.java:106) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.j ava:234) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java :123) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilde r.java:340) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:169) at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(Trans formerIdentityImpl.java:1101) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source ) at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknow n Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent Dispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un known Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Sour ce) Many thanks for the quickness of your previous reply. Any further help you might be able to offer would be appreciated. Regards, David Kelly Andreas Delmelle-2 wrote: On Aug 11, 2008, at 18:43, DavidJKelly wrote: Hi I have been trying to troubleshoot a java heap error for a good while, and I have researched the error messages on this site without luck. I have a 6000+ page document with numerous tables - the largest tables being at the front of the document, where they run fine. In dividing the document, I find that it gets to slightly over 3000 pages before it dies. Because the tables are simple two-column tables, I tried setting them up as lists in list-blocks, but I still get a similar error. Following are the errors from both the table and list versions: It depends on how large the individual page-sequences are. If you cram all 6000 pages into one page-sequence, and do not use forced breaks anywhere, you're going to need what looks like an unreasonable amount of heap to render the document (because the current implementation of the layout algorithm does not consider any page- break final, unless in case of a forced break, or the end of the page- sequence). If possible, try to break up the document into multiple page- sequences, and the issue should disappear. Other hint: if the document contains a lot of fo:inlines, try simply replacing those with fo:wrapper. Cheers Andreas - To unsubscribe, e
Re: Java heap overflow error - unknown reason
Are you actually giving FOP a little memory to play with? I mean a little more than the 64MB allocated by default? FOP is still a bit memory-intensive, but 100 pages (per page-sequence) should easily be handled with less than 512MB. If you can, post a link to an FO file. That would allow us to do some profiling to see why this happens (if my very obvious tip above doesn't apply). On 12.08.2008 21:53:25 DavidJKelly wrote: Andreas, Most of the book was in fact in a single page sequence. I attempted the three fixes you suggested, but with no luck. The FO is now in page sequences less than 100 pages each, and all fo:inlines are now fo:wrappers. I have also removed all keep-together and keep-with attributes. At risk of repetition, here is the error I get: WARNING: Line 2 of a paragraph overflows the available area by 400mpt. (fo:block , location: 46211/114) Exception in thread main java.lang.OutOfMemoryError: Java heap space at org.apache.fop.layoutmgr.inline.TextLayoutManager.createTextArea(Text LayoutManager.java:408) at org.apache.fop.layoutmgr.inline.TextLayoutManager.addAreas(TextLayout Manager.java:361) at org.apache.fop.layoutmgr.inline.LineLayoutManager.addInlineArea(LineL ayoutManager.java:1716) at org.apache.fop.layoutmgr.inline.LineLayoutManager.addAreas(LineLayout Manager.java:1568) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.AreaAdditionUtil.addAreas(AreaAdditionUtil.j ava:121) at org.apache.fop.layoutmgr.FlowLayoutManager.addAreas(FlowLayoutManager .java:305) at org.apache.fop.layoutmgr.PageBreaker.addAreas(PageBreaker.java:241) at org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.jav a:508) at org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.jav a:371) at org.apache.fop.layoutmgr.PageBreaker.doPhase3(PageBreaker.java:262) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.jav a:346) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.jav a:264) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(Pag eSequenceLayoutManager.java:106) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.j ava:234) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java :123) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilde r.java:340) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:169) at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(Trans formerIdentityImpl.java:1101) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source ) at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknow n Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent Dispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un known Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Sour ce) Many thanks for the quickness of your previous reply. Any further help you might be able to offer would be appreciated. Regards, David Kelly Andreas Delmelle-2 wrote: On Aug 11, 2008, at 18:43, DavidJKelly wrote: Hi I have been trying to troubleshoot a java heap error for a good while, and I have researched the error messages on this site without luck. I have a 6000+ page document with numerous tables - the largest tables being at the front of the document, where they run fine. In dividing the document, I find that it gets to slightly over 3000 pages before it dies. Because the tables are simple two-column tables, I tried setting them up as lists in list-blocks, but I still get a similar error. Following are the errors from both the table and list versions: It depends on how large the individual page-sequences are. If you cram all 6000 pages into one page-sequence, and do not use forced breaks anywhere, you're going to need what looks like
Java heap overflow error - unknown reason
I have been trying to troubleshoot a java heap error for a good while, and I have researched the error messages on this site without luck. I have a 6000+ page document with numerous tables - the largest tables being at the front of the document, where they run fine. In dividing the document, I find that it gets to slightly over 3000 pages before it dies. Because the tables are simple two-column tables, I tried setting them up as lists in list-blocks, but I still get a similar error. Following are the errors from both the table and list versions: TABLE: --- Nested Exception --- java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390) at java.lang.StringBuffer.append(StringBuffer.java:224) at org.apache.fop.layoutmgr.AbstractLayoutManager.addChildLM(AbstractLayoutManager.java:275) at org.apache.fop.layoutmgr.AbstractLayoutManager.addChildLMs(AbstractLayoutManager.java:289) at org.apache.fop.layoutmgr.BlockLayoutManager.createLineManager(BlockLayoutManager.java:205) at org.apache.fop.layoutmgr.BlockLayoutManager.createNextChildLMs(BlockLayoutManager.java:173) at org.apache.fop.layoutmgr.LMiter.hasNext(LMiter.java:40) at org.apache.fop.layoutmgr.AbstractLayoutManager.getChildLM(AbstractLayoutManager.java:116) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getBreakBefore(BlockStackingLayoutManager.java:978) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.addKnuthElementsForBreakBefore(BlockStackingLayoutManager.java:954) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:253) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:116) at org.apache.fop.layoutmgr.table.TableCellLayoutManager.getNextKnuthElements(TableCellLayoutManager.java:170) at org.apache.fop.layoutmgr.table.RowGroupLayoutManager.createElementsForRowGroup(RowGroupLayoutManager.java:120) at org.apache.fop.layoutmgr.table.RowGroupLayoutManager.getNextKnuthElements(RowGroupLayoutManager.java:60) at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getKnuthElementsForRowIterator(TableContentLayoutManager.java:220) at org.apache.fop.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements(TableContentLayoutManager.java:172) at org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements(TableLayoutManager.java:247) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:294) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:116) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:294) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:116) at org.apache.fop.layoutmgr.StaticContentLayoutManager$StaticContentBreaker.getNextKnuthElements(StaticContentLayoutManager.java:318) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:552) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:302) at org.apache.fop.layoutmgr.StaticContentLayoutManager.doLayout(StaticContentLayoutManager.java:240) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.layoutSideRegion(PageSequenceLayoutManager.java:156) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.finishPage(PageSequenceLayoutManager.java:163) at org.apache.fop.layoutmgr.AbstractPageSequenceLayoutManager.makeNewPage(AbstractPageSequenceLayoutManager.java:284) at org.apache.fop.layoutmgr.PageBreaker.handleBreakTrait(PageBreaker.java:494) LIST: --- Nested Exception --- java.lang.OutOfMemoryError: Java heap space at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getMethod0(Class.java:2670) at java.lang.Class.getMethod(Class.java:1603) at org.apache.commons.logging.LogFactory.getContextClassLoader(LogFactory.java:438) at org.apache.commons.logging.LogFactory$1.run(LogFactory.java:222) at java.security.AccessController.doPrivileged(Native Method) at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:218) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351) at org.apache.fop.layoutmgr.inline.BasicScaledBaselineTable.init(BasicScaledBaselineTable.java:37) at org.apache.fop.layoutmgr.inline.ScaledBaselineTableFactory.makeFontScaledBaselineTable(ScaledBaselineTableFactory.java:44
Re: Java heap overflow error - unknown reason
On Aug 11, 2008, at 18:43, DavidJKelly wrote: Hi I have been trying to troubleshoot a java heap error for a good while, and I have researched the error messages on this site without luck. I have a 6000+ page document with numerous tables - the largest tables being at the front of the document, where they run fine. In dividing the document, I find that it gets to slightly over 3000 pages before it dies. Because the tables are simple two-column tables, I tried setting them up as lists in list-blocks, but I still get a similar error. Following are the errors from both the table and list versions: It depends on how large the individual page-sequences are. If you cram all 6000 pages into one page-sequence, and do not use forced breaks anywhere, you're going to need what looks like an unreasonable amount of heap to render the document (because the current implementation of the layout algorithm does not consider any page- break final, unless in case of a forced break, or the end of the page- sequence). If possible, try to break up the document into multiple page- sequences, and the issue should disappear. Other hint: if the document contains a lot of fo:inlines, try simply replacing those with fo:wrapper. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.93: Java Heap Space OutOfMemory
On Jul 11, 2007, at 08:21, Daniel Noll wrote: Hi Daniel On Tuesday 10 July 2007 02:32:30 Andreas L Delmelle wrote: Not really. It's a matter of using common sense, I guess... Putting all content together inside one and the same page-sequence is bound to get you in trouble. Is there an alternative for situations where the content comes from elsewhere? Problem is it's not trivial to determine where to break the page sequence. If it breaks in the middle of a page, then you end up with half a page of fail. I know... The source XML has to have some logical boundaries/groups at which you can start a new page-sequence, otherwise this tip is useless. Currently there is no alternative, I'm afraid (unless you consider / not/ using FOP an option...) Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.93: Java Heap Space OutOfMemory
We also have a memory issue due to very large page sequences. One thing we do is offer the customer two report outputs: PDF and something called PDF Simple. PDF is the regular report that has a single page sequence and can consume a lot of memory. The simple output is the same report, but we break the page sequences every n number if lines. It does result in some half populated pages, but the memory and speed improvement make it worth it to our customers. -Lou Andreas L Delmelle [EMAIL PROTECTED] wrote on 07/11/2007 01:09:29 PM: On Jul 11, 2007, at 08:21, Daniel Noll wrote: Hi Daniel On Tuesday 10 July 2007 02:32:30 Andreas L Delmelle wrote: Not really. It's a matter of using common sense, I guess... Putting all content together inside one and the same page-sequence is bound to get you in trouble. Is there an alternative for situations where the content comes from elsewhere? Problem is it's not trivial to determine where to break the page sequence. If it breaks in the middle of a page, then you end up with half a page of fail. I know... The source XML has to have some logical boundaries/groups at which you can start a new page-sequence, otherwise this tip is useless. Currently there is no alternative, I'm afraid (unless you consider / not/ using FOP an option...) Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.93: Java Heap Space OutOfMemory
On Jul 11, 2007, at 20:12, [EMAIL PROTECTED] wrote: Hi Lou We also have a memory issue due to very large page sequences. One thing we do is offer the customer two report outputs: PDF and something called PDF Simple. PDF is the regular report that has a single page sequence and can consume a lot of memory. The simple output is the same report, but we break the page sequences every n number if lines. It does result in some half populated pages, but the memory and speed improvement make it worth it to our customers. Just curious: how exactly do you break the page-sequences? I've seen it done in some Bugzilla, IIC, but I cannot remember the details. All I remember is that it was a very dirty hack... In the end, that page-sequence boundary is currently not a major issue if you take into account: a) what you get in return (absolutely gratis) b) how easy it is sometimes to sell the dirty solution as a necessary evil (especially when it means it will cost the customer less) c) that no one ever really sees much more of these 1000-paged reports than the first 20 pages anyway :) FYI: Note that a similar limit also applies to blocks, although people tend to run into this far less often. In case of very large page- sequences, those generally never make it to the layout stage. The heap will be filled with the page-sequence and all its descendants. A huge block of text OTOH still occupies relatively little space in terms of memory, but it's only when layout begins that the memory usage increases drastically and FOP finally dies because of the ridiculous amount of break-possibilities the layout algorithm is forced to consider. Give it a few forced breaks and everything runs smoothly. That said, we'd definitely appreciate any suggestions in terms of architectural changes to shift this logic of forcing breaks into FOP's black box. Something like an internal threshold, in terms of memory consumption, number of Java object instances or the amount of break-possibilities? Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.93: Java Heap Space OutOfMemory
An interesting bit of synchronicity, Lou - one of my clients does the same thing. For every client who wants the whole thing, I think there's about three who use the simple format. Both use FOP to produce a PDF, but the results and processing times are very different. Often, negotiating with your end users (explaining the situation and offering some choices) both gets one out of a tough box and gives the users some choices they like. FWIW Jay Bryant Bryant Communication Services - Original Message - From: [EMAIL PROTECTED] To: fop-users@xmlgraphics.apache.org Sent: Wednesday, July 11, 2007 1:12 PM Subject: Re: FOP 0.93: Java Heap Space OutOfMemory We also have a memory issue due to very large page sequences. One thing we do is offer the customer two report outputs: PDF and something called PDF Simple. PDF is the regular report that has a single page sequence and can consume a lot of memory. The simple output is the same report, but we break the page sequences every n number if lines. It does result in some half populated pages, but the memory and speed improvement make it worth it to our customers. -Lou Andreas L Delmelle [EMAIL PROTECTED] wrote on 07/11/2007 01:09:29 PM: On Jul 11, 2007, at 08:21, Daniel Noll wrote: Hi Daniel On Tuesday 10 July 2007 02:32:30 Andreas L Delmelle wrote: Not really. It's a matter of using common sense, I guess... Putting all content together inside one and the same page-sequence is bound to get you in trouble. Is there an alternative for situations where the content comes from elsewhere? Problem is it's not trivial to determine where to break the page sequence. If it breaks in the middle of a page, then you end up with half a page of fail. I know... The source XML has to have some logical boundaries/groups at which you can start a new page-sequence, otherwise this tip is useless. Currently there is no alternative, I'm afraid (unless you consider / not/ using FOP an option...) Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.93: Java Heap Space OutOfMemory
Andreas: I have several _wonderful_ users that demand to generate several thousand page reports and kill many, many trees, all in the name of something. I should just render the first and last 20 pages and fill the middle 1960 pages with blanks - I bet they never notice. :) With that said, this is how I break the page sequences: xsl:for-each select=reportrow[position() mod $rowCount = 1] fo:page-sequence master-reference=generic language=en country=us fo:static-content flow-name=xsl-region-before snip/ /fo:static-content fo:static-content flow-name=xsl-region-after snip/ /fo:static-content fo:flow flow-name=xsl-region-body fo:table table-layout=fixed width=100% xsl:for-each select=columns/column fo:table-column snip/ /fo:table-column /xsl:for-each fo:table-header snip/ /fo:table-header fo:table-body xsl:for-each select=.|following-sibling::reportrow[position() lt; $rowCount] fo:table-row snip/ /fo:table-row /xsl:for-each /fo:table-body /fo:table /fo:flow /fo:page-sequence /xsl:for-each I did not know that block could also consume a lot of memory - it gives me something else to check - thanks. -Lou Andreas L Delmelle [EMAIL PROTECTED] wrote on 07/11/2007 02:51:45 PM: On Jul 11, 2007, at 20:12, [EMAIL PROTECTED] wrote: Hi Lou We also have a memory issue due to very large page sequences. One thing we do is offer the customer two report outputs: PDF and something called PDF Simple. PDF is the regular report that has a single page sequence and can consume a lot of memory. The simple output is the same report, but we break the page sequences every n number if lines. It does result in some half populated pages, but the memory and speed improvement make it worth it to our customers. Just curious: how exactly do you break the page-sequences? I've seen it done in some Bugzilla, IIC, but I cannot remember the details. All I remember is that it was a very dirty hack... In the end, that page-sequence boundary is currently not a major issue if you take into account: a) what you get in return (absolutely gratis) b) how easy it is sometimes to sell the dirty solution as a necessary evil (especially when it means it will cost the customer less) c) that no one ever really sees much more of these 1000-paged reports than the first 20 pages anyway :) FYI: Note that a similar limit also applies to blocks, although people tend to run into this far less often. In case of very large page- sequences, those generally never make it to the layout stage. The heap will be filled with the page-sequence and all its descendants. A huge block of text OTOH still occupies relatively little space in terms of memory, but it's only when layout begins that the memory usage increases drastically and FOP finally dies because of the ridiculous amount of break-possibilities the layout algorithm is forced to consider. Give it a few forced breaks and everything runs smoothly. That said, we'd definitely appreciate any suggestions in terms of architectural changes to shift this logic of forcing breaks into FOP's black box. Something like an internal threshold, in terms of memory consumption, number of Java object instances or the amount of break-possibilities? Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOP 0.93: Java Heap Space OutOfMemory
Seems there was not enough space on harddisk for generating the PDF-Output with FOP 0.93. Is there a option for FOP to display how many space on harddisk is needed while generating a PDF? This time over 200 MB were needed by FOP to generate a less than 2 MB big PDF-File. Regards, Kerstin --- [EMAIL PROTECTED] schrieb: While generating a PDF from XML+XSL using FOP 0.93, FOP stops with Exception in thread main java.lang.OutOfMemoryError: Java heap space. Are their any limitations set in FOP or this is just a problem of to few system memory? The generated PDF have more than 71 pages. - Besseren Schutz gegen Spam - jetzt bei dem neuen Yahoo! Mail . __ Die besten Tipps und Tricks fürs Grillen. BE A BETTER GRILLMEISTER! www.yahoo.de/clever - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.93: Java Heap Space OutOfMemory
On Jul 9, 2007, at 09:30, [EMAIL PROTECTED] leeloo5e79- [EMAIL PROTECTED] wrote: Hi Seems there was not enough space on harddisk for generating the PDF-Output with FOP 0.93. Not enough disk space? So your JVM wanted to swap but couldn't? Is there a option for FOP to display how many space on harddisk is needed while generating a PDF? Not really. It's a matter of using common sense, I guess... Putting all content together inside one and the same page-sequence is bound to get you in trouble. I managed to let FOP die with an OOM once, for a document that contained a little over 40 pages... On the other hand, some users have reported generating documents of +1 pages without any particular problem. FWIW: the current trunk version already contains some optimizations in terms of memory usage. If you're at liberty to try it out, and see if it helps you... All feedback is welcome. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FOP 0.93: Java Heap Space OutOfMemory
While generating a PDF from XML+XSL using FOP 0.93, FOP stops with Exception in thread main java.lang.OutOfMemoryError: Java heap space. Are their any limitations set in FOP or this is just a problem of to few system memory? The generated PDF have more than 71 pages. - Besseren Schutz gegen Spam - jetzt bei dem neuen Yahoo! Mail .
Re: FOP 0.93: Java Heap Space OutOfMemory
Try increasing the amount of memory available to your VM by using the
java extended argument option -Xmx{???}M, where {???} is the number of
megabytes you wish to make available to the java virtual machine.
Adrian.
[EMAIL PROTECTED] wrote:
While generating a PDF from XML+XSL using FOP 0.93, FOP stops with
Exception in thread main java.lang.OutOfMemoryError: Java heap
space. Are their any limitations set in FOP or this is just a problem
of to few system memory?
The generated PDF have more than 71 pages.
Besseren Schutz gegen Spam - jetzt bei dem neuen Yahoo! Mail
http://de.rd.yahoo.com/evt=40589/*http://de.docs.yahoo.com/ymail/landing.html
.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.93: Java Heap Space OutOfMemory
On Jul 2, 2007, at 17:12, [EMAIL PROTECTED] leeloo5e79- [EMAIL PROTECTED] wrote: Hi, While generating a PDF from XML+XSL using FOP 0.93, FOP stops with Exception in thread main java.lang.OutOfMemoryError: Java heap space. Are their any limitations set in FOP or this is just a problem of to few system memory? The generated PDF have more than 71 pages. Apart from what Adrian already replied (increase JVM max. heap space), it could also help, if possible for you of course, to structure the FO differently. There are no absolute limits set in FOP, but there are limits that follow from the current architecture. A document containing 1000 page- sequences of 10 pages without forward references should be processed w/o problems. A document containing 1 page-sequence of 50 pages may already be enough for FOP to run out of memory... Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OutOfMemoryError: Java heap space
As has been said many times on this list, FOP still has some restrictions concerning the handling of large documents. There are a bunch of work-arounds, most of them documented on the website and many of them elaborated on this list. The long-term solution is to allocate resources to help us improve FOP in this direction. Ideas are there. Resources are not. Yet, anyway. On 30.05.2006 01:10:15 Daniel Noll wrote: David Delbecq wrote: Increase memory allocated to java with -Xmx256m That's an invalid solution for two reasons: 1. Customers who use our application often only have about 256MB maximum RAM or less, and setting more than that will cause excessive paging to disk. 2. We're already using -Xmx512m and FOP is *still* running out of memory. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OutOfMemoryError: Java heap space
Daniel Noll wrote: David Delbecq wrote: Increase memory allocated to java with -Xmx256m That's an invalid solution for two reasons: 1. Customers who use our application often only have about 256MB maximum RAM or less, and setting more than that will cause excessive paging to disk. 2. We're already using -Xmx512m and FOP is *still* running out of memory. This is a FAQ. Read the section on FOP Memory: http://xmlgraphics.apache.org/fop/faq.html#OutOfMemoryException The short answer is FOP keeps an entire page-sequence in memory. You probably need to break up your text into multiple page sequences to avoid keeping the entire document in memory. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OutOfMemoryError: Java heap space
Increase memory allocated to java with -Xmx256m Andre Groeneveld wrote: Hi Daniel, I'm getting the same problem when loading an xml File that is round about 30MB, have you found a solution for your problem yet? -Original Message- From: Daniel Noll [mailto:[EMAIL PROTECTED] Sent: 29 May 2006 06:17 AM To: FOP Users Mailing List Subject: OutOfMemoryError: Java heap space Hi, folks. I am working on improving our application by making it able to cope with larger text than it can currently handle. My test document is some 36MB of text, which is really just the same sentence over and over. We first generate the document as HTML (for simpler templating), and this part works, the resulting HTML being around 39MB. We then convert the HTML to XSL-FO, and that part is working as well, the resulting FO being around 45MB. The resulting XSL-FO looks a little like this: . (skipping the top of the file.) . . This is a test file with an awful lot of text.fo:block/ This is a test file with an awful lot of text.fo:block/ . . . (skipping the bottom of the file.) (What it's doing is simulating a br/. I got that idea a long time ago from another post on this mailing list.) Anyway, when I get to the part where the FO is rendered to PDF, FOP throws an OutOfMemoryError. Is FOP trying to keep the entire document in memory, and if so, is there some way around it? Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OutOfMemoryError: Java heap space
David Delbecq wrote: Increase memory allocated to java with -Xmx256m That's an invalid solution for two reasons: 1. Customers who use our application often only have about 256MB maximum RAM or less, and setting more than that will cause excessive paging to disk. 2. We're already using -Xmx512m and FOP is *still* running out of memory. Daniel -- Daniel Noll Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, AustraliaPh: +61 2 9280 0699 Web: http://www.nuix.com.au/Fax: +61 2 9212 6902 This message is intended only for the named recipient. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this message or attachment is strictly prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OutOfMemoryError: Java heap space
Hi, folks. I am working on improving our application by making it able to cope with larger text than it can currently handle. My test document is some 36MB of text, which is really just the same sentence over and over. We first generate the document as HTML (for simpler templating), and this part works, the resulting HTML being around 39MB. We then convert the HTML to XSL-FO, and that part is working as well, the resulting FO being around 45MB. The resulting XSL-FO looks a little like this: . (skipping the top of the file.) . . This is a test file with an awful lot of text.fo:block/ This is a test file with an awful lot of text.fo:block/ . . . (skipping the bottom of the file.) (What it's doing is simulating a br/. I got that idea a long time ago from another post on this mailing list.) Anyway, when I get to the part where the FO is rendered to PDF, FOP throws an OutOfMemoryError. Is FOP trying to keep the entire document in memory, and if so, is there some way around it? Daniel -- Daniel Noll Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, AustraliaPh: +61 2 9280 0699 Web: http://www.nuix.com.au/Fax: +61 2 9212 6902 This message is intended only for the named recipient. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this message or attachment is strictly prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
