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: 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: 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