Re: 200K increase for xml - pdf when using images
Joerg is right. It's the color profile bug. I don't even have to look at the barcode image because it doesn't matter if there's a color profile attached. FOP 0.92beta will add one anyway due to the bug. Compiling FOP Trunk is very simple: - Install a Subversion client - Install Apache Ant - Check out FOP - Run ant from the FOP's home directory All neatly described on the website: http://xmlgraphics.apache.org/fop/trunk/compiling.html http://xmlgraphics.apache.org/repo.html On 02.06.2006 00:39:15 Rick Roen wrote: I've attached a sample of a png file for the postnet barcode. I'm a complete java novice and last time I tried to compile the latest version I spent hours and got nothing since I don't know the basics. Can you check from the attachment to see if it has a color profile? Rick -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Thursday, June 01, 2006 4:27 PM To: fop-users@xmlgraphics.apache.org Subject: Re: 200K increase for xml - pdf when using images Rick Roen wrote: When I add two postnet bar codes, each of which are 1K png files, the pdf goes to about 225K. Why does it grow so large? Wild guess: there was a problem with embedding large color profiles into the PDF if the original pictures didn't contain a color profile. The problem has been fixed in SVN. Could you grab a recent snapshot and check whether the problem persists? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Preprocessing
Hi, Would you perhaps have a demo/example showing the best way of postprocessing the FO after XSL transformation before it is fed to FOP? Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 13:27 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException Frankly, migrating this kind of extension could be a problem. But I'm not sure. At any rate, there's no layout() method anymore and the FO tree itself had a few changes, too. If I were you I wouldn't implement something like that as a FOP extension but as a generic, SAX-based pre-processor which is independent of the FO processor. That would make the thing much more versatile. On 30.05.2006 13:13:16 Raphael Parree wrote: The extension performs syntax checking and color highlighting of various languages (JAVA, JSP, HTML, XML, SQL, HQL, EJBQL etc). It does not generate SVG, but produces FO where it changes the font attributes. It extends the FObj and relies on the layout method to call an addText method for each token. I can't recall from which example I obtained the skeleton code (especially the addText method). Do you think it will be an easy transition? I have been postponing the move, but am aware that one day I will have to make it ;) -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 12:40 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException The extension API has been stable for a while. A few months ago I've added some additional gadgets I needed for Barcode4J. I don't expect any major changes anymore. Backwards-incompatible changes are highly unlikely, but no guarantees. So far, there's no documentation for writing extensions. I usually point people at Barcode4J as the prime example. :-) The examples directory in the distribution (MathML and plan extensions) can also help. The migration shouldn't be too difficult. A few things have changed but most of your custom code can stay the same. I'm pretty confident that you can do the migration in 2 or 3 hours max if your extension simply generates SVG. Now, I'm curious: What kind of extensions did you implement? On 30.05.2006 11:57:13 Raphael Parree wrote: Hi, I would like to move to 0.92beta, but have so far been reluctant to make the move due to the FOP extension we have written. Is it safe to start porting the extensions (IOW is the extension API stable?). Is there documentation available on writing extensions for the new release (or even better on how to migrate your extensions?) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preprocessing
I don't have a working example ready to pass over but I can give you some pointers. Essentially, I think you'd best implement an org.xml.sax.XMLFilter (you can case XMLFilterImpl as a base class). That's the recommended way. You can get some hints to the approach from: http://www.javalobby.org/java/forums/m91825016.html http://www.javalobby.org/forums/thread.jspa?threadID=16216tstart=0 In FOP we also have code that operates similarly although it's not a filter/conversion operation on the XML level. Since we're on the receiving end of the SAX chain and thus have to operate purely on the passive side, we can't use XMLFilter. Everything is implemented as a passive ContentHandler (active would mean it would be an XMLReader with parse() methods). This is all code used to build the FO tree and foreign elements. Building blocks are: - org.apache.fop.fo.FOTreeBuilder and it's nested MainFOHandler. - org.apache.fop.util.DelegatingContentHandler - org.apache.fop.util.ContentHandlerFactory - org.apache.fop.util.ContentHandlerFactoryRegistry But don't look too much at FOP. I'd use the XMLFilter approach. Good luck! On 02.06.2006 08:56:25 Raphael Parree wrote: Hi, Would you perhaps have a demo/example showing the best way of postprocessing the FO after XSL transformation before it is fed to FOP? Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 13:27 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException Frankly, migrating this kind of extension could be a problem. But I'm not sure. At any rate, there's no layout() method anymore and the FO tree itself had a few changes, too. If I were you I wouldn't implement something like that as a FOP extension but as a generic, SAX-based pre-processor which is independent of the FO processor. That would make the thing much more versatile. On 30.05.2006 13:13:16 Raphael Parree wrote: The extension performs syntax checking and color highlighting of various languages (JAVA, JSP, HTML, XML, SQL, HQL, EJBQL etc). It does not generate SVG, but produces FO where it changes the font attributes. It extends the FObj and relies on the layout method to call an addText method for each token. I can't recall from which example I obtained the skeleton code (especially the addText method). Do you think it will be an easy transition? I have been postponing the move, but am aware that one day I will have to make it ;) -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 12:40 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException The extension API has been stable for a while. A few months ago I've added some additional gadgets I needed for Barcode4J. I don't expect any major changes anymore. Backwards-incompatible changes are highly unlikely, but no guarantees. So far, there's no documentation for writing extensions. I usually point people at Barcode4J as the prime example. :-) The examples directory in the distribution (MathML and plan extensions) can also help. The migration shouldn't be too difficult. A few things have changed but most of your custom code can stay the same. I'm pretty confident that you can do the migration in 2 or 3 hours max if your extension simply generates SVG. Now, I'm curious: What kind of extensions did you implement? On 30.05.2006 11:57:13 Raphael Parree wrote: Hi, I would like to move to 0.92beta, but have so far been reluctant to make the move due to the FOP extension we have written. Is it safe to start porting the extensions (IOW is the extension API stable?). Is there documentation available on writing extensions for the new release (or even better on how to migrate your extensions?) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
font size and white spaces
Hello, we have problems with fo:blocks and text-size. We use True Type Fonts, but we can't fill the fo:block completely. We have no problem filling it horizontally, but there are white spaces above and below the text after rendering the pdf-file. Here an example: fo:table-row height=40.0pt fo:table-cell /fo:table-cell fo:table-cell border-bottom-style=solid border-bottom-width=1.0pt border-left-style=solid border-left-width=1.0pt border-right-style=solid border-right-width=1.0pt border-top-style=solid border-top-width=1.0pt text-align=center display-align=before fo:block white-space-collapse=true text-align=center color=#ff font-family=FranklinGothic-Heavy font-size=40.0pt line-height=40pt xsl:value-of disable-output-escaping=no select=price_outlet_entire/ /fo:block /fo:table-cell [no paddings!] Our questions: - How can we avoid that white spaces? - What does font-size really mean? How is the font-size corresponding with the font-height? How can we detemine the maximum font-height of a certain text? Are there any methods in FOP? - We have tested Type1 fonts. White spaces are much smaller there. Why? Rainer Kring mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: font size and white spaces
Rainer, I think this is a result of font metrics. The font metrics in TrueType fonts are a mess (various fonts interpreting the values differently). I've recently look into this and I think I have been able to improve the metrics handling for TrueType fonts [1]. For Type 1 fonts the metrics situation is a lot clearer and that's why Type 1 fonts work better. [1] http://xmlgraphics.apache.org/fop/changes.html#version_FOP%20Trunk (Bugfix: Improved baseline detection in TTFReader for TrueType fonts. (JM)) Would you please do me a favor and test your documents with the latest FOP from Subversion? Or at least you have to regenerate the font metrics for the font again with the TTFReader from FOP Trunk. I've just tested it it the result was better with your snippet. On 02.06.2006 10:02:38 Kring, Rainer wrote: Hello, we have problems with fo:blocks and text-size. We use True Type Fonts, but we can't fill the fo:block completely. We have no problem filling it horizontally, but there are white spaces above and below the text after rendering the pdf-file. Here an example: fo:table-row height=40.0pt fo:table-cell /fo:table-cell fo:table-cell border-bottom-style=solid border-bottom-width=1.0pt border-left-style=solid border-left-width=1.0pt border-right-style=solid border-right-width=1.0pt border-top-style=solid border-top-width=1.0pt text-align=center display-align=before fo:block white-space-collapse=true text-align=center color=#ff font-family=FranklinGothic-Heavy font-size=40.0pt line-height=40pt xsl:value-of disable-output-escaping=no select=price_outlet_entire/ /fo:block /fo:table-cell [no paddings!] Our questions: - How can we avoid that white spaces? - What does font-size really mean? How is the font-size corresponding with the font-height? How can we detemine the maximum font-height of a certain text? Are there any methods in FOP? - We have tested Type1 fonts. White spaces are much smaller there. Why? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FOP/Cocoon performance tips?
Hi all, I'm running quite complex XML XSL-FO PDF transformation generating book packages. One package consists of: - 2 full books (Student Guide, Instructor Guide) of approx 200 pages each - separate handouts in 3 booklets (each of 30-40 pages) All targets are generated from the same XML source. Average book contains 80-150 images. To generate the package takes about 10 minutes. I need to push this value down, as a client is not quite happy with it :| I'm looking for possible optimization in area of Cocoon/FOP config. (I know there can be also some 'resources' in xslt part of the job, but IMHO it would not bring too much at this point - I measured the time Xalan needs to transform xml to xsl-fo and it is just a fraction of time FOP needs to generate its output...) Environment: *Linux (Debian or Fedora) Cocoon (2.1.9) as part of Tomcat webapp; FOP 0.92beta with embed Xalan I hope there is many of you far more experienced with given set and you could give me some hints :) (FOP/Java environment, cocoon cache - what is worth to cache?) Thanks in advance Martin -- Martin Zak project manager, developer Ginger Alliance, s.r.o. Otakarova 15 140 00 Prague Czech Republic Office: tel +420 241 741 406 : fax +420 241 740 398 YM ID : zakmart Email : [EMAIL PROTECTED] http://www.gingerall.com http://www.ga-mme.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP/Cocoon performance tips?
Martin Zak schrieb: Hi all, I'm running quite complex XML XSL-FO PDF transformation generating book packages. One package consists of: - 2 full books (Student Guide, Instructor Guide) of approx 200 pages each - separate handouts in 3 booklets (each of 30-40 pages) All targets are generated from the same XML source. Average book contains 80-150 images. Which image format are you using? If you aren't using jpegs you might try it this format because those will be directly embedded in (PDF and PS) documents which is faster than decoding the images. Do you know Jeremias' presentation Apache FOP: Optimizing speed and memory consumption[1]? Seems we have no link on the FOP website ... -- Christian [1] http://people.apache.org/%7Ejeremias/slides/FOP%20Optimization%20Presentation%20ApacheCon%20EU%202005.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
image opacity and pdf compression
Hi, I would like to know if there is a way to add images with reduced opacity into a pdf. Also, can a pdf be optimized/compressed? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP/Cocoon performance tips?
hi Christian, thanks for useful tip - it's nice overview. I'll focus on the part re image formats now, which surprised me a lot - I didn't expect so big differences between formats in processing! Anyway it may be worth to post this presentation somewhere in FOP resources/links section... Cheers Martin Christian Geisert wrote: Martin Zak schrieb: Hi all, I'm running quite complex XML XSL-FO PDF transformation generating book packages. One package consists of: - 2 full books (Student Guide, Instructor Guide) of approx 200 pages each - separate handouts in 3 booklets (each of 30-40 pages) All targets are generated from the same XML source. Average book contains 80-150 images. Which image format are you using? If you aren't using jpegs you might try it this format because those will be directly embedded in (PDF and PS) documents which is faster than decoding the images. Do you know Jeremias' presentation Apache FOP: Optimizing speed and memory consumption[1]? Seems we have no link on the FOP website ... -- Martin Zak project manager, developer Ginger Alliance, s.r.o. Otakarova 15 140 00 Prague Czech Republic Office: tel +420 241 741 406 : fax +420 241 740 398 YM ID : zakmart Email : [EMAIL PROTECTED] http://www.gingerall.com http://www.ga-mme.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: image opacity and pdf compression
On 02.06.2006 12:26:58 Razvan Pat wrote: I would like to know if there is a way to add images with reduced opacity into a pdf. Not using XSL-FO. If you wrap the image in SVG, then it's possible. Also, can a pdf be optimized/compressed? Not with FOP. You have to post-process the PDF. Tools are found here: http://xmlgraphics.apache.org/fop/resources.html#products-pdf Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: font size and white spaces
I try that next week. Then I'm going to write again. -Ursprüngliche Nachricht- Von: Jeremias Maerki [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 2. Juni 2006 10:42 An: fop-users@xmlgraphics.apache.org Betreff: Re: font size and white spaces Rainer, I think this is a result of font metrics. The font metrics in TrueType fonts are a mess (various fonts interpreting the values differently). I've recently look into this and I think I have been able to improve the metrics handling for TrueType fonts [1]. For Type 1 fonts the metrics situation is a lot clearer and that's why Type 1 fonts work better. [1] http://xmlgraphics.apache.org/fop/changes.html#version_FOP%20Trunk (Bugfix: Improved baseline detection in TTFReader for TrueType fonts. (JM)) Would you please do me a favor and test your documents with the latest FOP from Subversion? Or at least you have to regenerate the font metrics for the font again with the TTFReader from FOP Trunk. I've just tested it it the result was better with your snippet. On 02.06.2006 10:02:38 Kring, Rainer wrote: Hello, we have problems with fo:blocks and text-size. We use True Type Fonts, but we can't fill the fo:block completely. We have no problem filling it horizontally, but there are white spaces above and below the text after rendering the pdf-file. Here an example: fo:table-row height=40.0pt fo:table-cell /fo:table-cell fo:table-cell border-bottom-style=solid border-bottom-width=1.0pt border-left-style=solid border-left-width=1.0pt border-right-style=solid border-right-width=1.0pt border-top-style=solid border-top-width=1.0pt text-align=center display-align=before fo:block white-space-collapse=true text-align=center color=#ff font-family=FranklinGothic-Heavy font-size=40.0pt line-height=40pt xsl:value-of disable-output-escaping=no select=price_outlet_entire/ /fo:block /fo:table-cell [no paddings!] Our questions: - How can we avoid that white spaces? - What does font-size really mean? How is the font-size corresponding with the font-height? How can we detemine the maximum font-height of a certain text? Are there any methods in FOP? - We have tested Type1 fonts. White spaces are much smaller there. Why? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preprocessing
Thanks got the highlighter working again using an XMLFilter (working on 0.20.5). Trying now to move to 0.92, but that is giving many headaches...many Some content could not fit into a line/page after 50 attempts. Giving up to avoid an endless loop occur...(I am now moving first without the extension/filter) -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 02 June 2006 09:50 To: fop-users@xmlgraphics.apache.org Subject: Re: Preprocessing I don't have a working example ready to pass over but I can give you some pointers. Essentially, I think you'd best implement an org.xml.sax.XMLFilter (you can case XMLFilterImpl as a base class). That's the recommended way. You can get some hints to the approach from: http://www.javalobby.org/java/forums/m91825016.html http://www.javalobby.org/forums/thread.jspa?threadID=16216tstart=0 In FOP we also have code that operates similarly although it's not a filter/conversion operation on the XML level. Since we're on the receiving end of the SAX chain and thus have to operate purely on the passive side, we can't use XMLFilter. Everything is implemented as a passive ContentHandler (active would mean it would be an XMLReader with parse() methods). This is all code used to build the FO tree and foreign elements. Building blocks are: - org.apache.fop.fo.FOTreeBuilder and it's nested MainFOHandler. - org.apache.fop.util.DelegatingContentHandler - org.apache.fop.util.ContentHandlerFactory - org.apache.fop.util.ContentHandlerFactoryRegistry But don't look too much at FOP. I'd use the XMLFilter approach. Good luck! On 02.06.2006 08:56:25 Raphael Parree wrote: Hi, Would you perhaps have a demo/example showing the best way of postprocessing the FO after XSL transformation before it is fed to FOP? Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 13:27 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException Frankly, migrating this kind of extension could be a problem. But I'm not sure. At any rate, there's no layout() method anymore and the FO tree itself had a few changes, too. If I were you I wouldn't implement something like that as a FOP extension but as a generic, SAX-based pre-processor which is independent of the FO processor. That would make the thing much more versatile. On 30.05.2006 13:13:16 Raphael Parree wrote: The extension performs syntax checking and color highlighting of various languages (JAVA, JSP, HTML, XML, SQL, HQL, EJBQL etc). It does not generate SVG, but produces FO where it changes the font attributes. It extends the FObj and relies on the layout method to call an addText method for each token. I can't recall from which example I obtained the skeleton code (especially the addText method). Do you think it will be an easy transition? I have been postponing the move, but am aware that one day I will have to make it ;) -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 12:40 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException The extension API has been stable for a while. A few months ago I've added some additional gadgets I needed for Barcode4J. I don't expect any major changes anymore. Backwards-incompatible changes are highly unlikely, but no guarantees. So far, there's no documentation for writing extensions. I usually point people at Barcode4J as the prime example. :-) The examples directory in the distribution (MathML and plan extensions) can also help. The migration shouldn't be too difficult. A few things have changed but most of your custom code can stay the same. I'm pretty confident that you can do the migration in 2 or 3 hours max if your extension simply generates SVG. Now, I'm curious: What kind of extensions did you implement? On 30.05.2006 11:57:13 Raphael Parree wrote: Hi, I would like to move to 0.92beta, but have so far been reluctant to make the move due to the FOP extension we have written. Is it safe to start porting the extensions (IOW is the extension API stable?). Is there documentation available on writing extensions for the new release (or even better on how to migrate your extensions?) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 200K increase for xml - pdf when using images
Thanks Jeremias and Joerg, I downloaded the latest (you're right, it's not all that hard) and the resulting pdf is now 27K, not 225K!) Rick -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 12:27 AM To: fop-users@xmlgraphics.apache.org Subject: Re: 200K increase for xml - pdf when using images Joerg is right. It's the color profile bug. I don't even have to look at the barcode image because it doesn't matter if there's a color profile attached. FOP 0.92beta will add one anyway due to the bug. Compiling FOP Trunk is very simple: - Install a Subversion client - Install Apache Ant - Check out FOP - Run ant from the FOP's home directory All neatly described on the website: http://xmlgraphics.apache.org/fop/trunk/compiling.html http://xmlgraphics.apache.org/repo.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jeremias - offset error when xml - xsl -print
Jeremias, Perhaps you recall the problem I had with the top block offsetting 2 cm up and left with xml + xsl - print. Now that I have downloaded and built the latest release the problem is gone! Just an FYI. Rick
Re: Extra space between following tables
On Jun 1, 2006, at 14:16, Jeremias Maerki wrote: Andreas, I'm more than happy to delegate this to you if you volunteer because I have more than enough on my plate already. Thanks. Done. Turned out to be a very easy fix indeed. I'll also add the FO as a testcase for future reference shortly. Locally, the output seemed OK and didn't break anything, so I saw no reason to wait with the sources. Later, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep-Together Problems
Dear Jeremias (or other), As this is a commercial project I can offer to employ you (or one of the developers) to cure this problem that we are experiencing. If you are willing, please let me know your personal charge for completing the fix. I can be contacted directly at [EMAIL PROTECTED] if preferable. Regards, Ross - Original Message - From: Jeremias Maerki [EMAIL PROTECTED] To: fop-users@xmlgraphics.apache.org Sent: Monday, May 29, 2006 1:11 PM Subject: Re: Keep-Together Problems At the moment, only always is supported for keep values which causes the effect you've seen. So far nobody has implemented any refinements that will cause certain keep conditions to be relaxed if necessary as defined in XSL 1.0, chapter 4.8. The solution would be to implement finer rules to specify penalty values during element list generation. Currently, there's no work-around other than not to use keeps. On 23.05.2006 16:01:41 Ross Nicholls wrote: Hi there, I am currently working on migrating our large XSL-FO project from FOP v0.20.5 to the new v0.92. Everything is going great and the new version offers some excellent advantages over the older one, I'm really looking forward to the SVG and MIF (or similar) output implementations when they materialise. I do have one problem however: The new version (0.92 beta) doesn't seem to cope too well with Keep-Together on table-rows (or any block level area for that matter) when the contents are actually larger than a page. In the old version (0.20.5) I was able to put a keep-together on the table-row which meant that each product from the catalogue would not be split over 2 pages UNLESS the product was too big to fit on a page of it's own. But with the new version, when it encounters such a product (table-row, that contains multiple blocks and image content) it crashes with an error - something like Content does not fit in available area after 50 attempts, gave up to avoid an infinite loop. Unfortunately, this means that we can't go ahead with the upgrade to the new version of FOP and take advantage of all the wonderful improvements - as the keep-togethers are very important. Does anyone have any idea how I can get round this problem, or is there a fix available or possible??? I appreciate any help or comments anyone can give. Kindest Regards, Ross Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Very large files to PDF
hello, for use in my report system i need to render reports with 30k pages into a single PDF file. generating single XSL:FO files (size up to 2,3GB) causes OutOfMemory exception. the report system is also able to generate the report in parts down to one page per XSL:FO file so i modified the PDFRenderer of 0.92Beta to render various sources into the same destination - and it works. th price is a personalized version of FOP and i do not like this. has anyone done anything like this before and found a more elegant solution ? thanks for all help stefan -- stefan ziel clan informática do brasil ltda. mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Very large files to PDF
On Jun 2, 2006, at 20:49, Stefan Ziel wrote: Hi, for use in my report system i need to render reports with 30k pages into a single PDF file. generating single XSL:FO files (size up to 2,3GB) causes OutOfMemory exception. the report system is also able to generate the report in parts down to one page per XSL:FO file so i modified the PDFRenderer of 0.92Beta to render various sources into the same destination - and it works. th price is a personalized version of FOP and i do not like this. has anyone done anything like this before and found a more elegant solution ? FOP's Intermediate Format[*] might offer a solution here (?) Generate separate documents, and concatenate the area trees...? On another note: what exactly is the structure of your FO-source? Do you work with multiple, smaller page-sequences, or one huge flow containing everything? Do you use forward-references to the end of the document? [*] see: http://xmlgraphics.apache.org/fop/0.92/intermediate.html HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What happened to base dir in 0.92?
We store our images and font metrics files in a
resource directory in our war file. Using the
following code in 0.20.5, we could access these images
and font metrics from within the war file.
org.apache.fop.configuration.Configuration.put(
baseDir,
AbstractDataRetriever.class.getResource(resource/).getFile());
org.apache.fop.configuration.Configuration.put(
fontBaseDir,
AbstractDataRetriever.class.getResource(resource/).getFile());
File userConfigFile = new
File(AbstractDataRetriever.class.getResource(
resource/userconfig.xml).getFile());
try
{
new
org.apache.fop.apps.Options(userConfigFile);
}
catch (org.apache.fop.apps.FOPException fope)
{
LOG.error(FOP initialization failed!,
fope);
}
With 0.92, there doesn't seem to be a mechanism for
initializing the baseDir anymore. Our images are no
longer showing up in the generated PDF files. Here is
the 0.92 initialization code:
try
{
FOP_FACTORY.setUserConfig(
AbstractDataRetriever.class.getResource(
resource/userconfig.xml).getFile());
FOP_FACTORY.setFontBaseURL(
AbstractDataRetriever.class.getResource(
resource/).getFile());
}
catch (Throwable t)
{
LOG.error(FOP initialization failed!, t);
}
How can we configure FOP version 0.92 to find images
in our war file?
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
