Re: FOP 1.1: Rendering problem with overflowing table cells
Hello Luis, the problem with this approach is that not all setter-methods that were available in FopFactory are now available in the builder. Also, please note that the docs haven't been updated, they still suggest to do it the old way. For example, if you look at http://xmlgraphics.apache.org/fop/trunk/embedding.html#config-internal you'll find that the first two methods listed there are not available in the builder. Kind regards, Ulrich Luis Bernardo wrote: See this thread: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201302.mbox/%3c512d5b3c.8060...@gmail.com%3e On Wednesday, May 29, 2013, Ulrich Mayring wrote: Ooops, the newest Nightly Build has changed the Interface of FopFactory and FontManager. All the setter-methods in those classes are gone. How can I programmatically configure FOP now? The docs under http://xmlgraphics.apache.org/**fop/trunk/embedding.html#**config-internalhttp://xmlgraphics.apache.org/fop/trunk/embedding.html#config-internalstill suggest the old way. cheers, Ulrich Ulrich Mayring wrote: Hi Glenn, thanks for the pointer, your suspicion was correct. With the latest nightly build the page is rendered like it was in FOP 0.95, which I believe is the correct way. Thanks a lot, Ulrich Glenn Adams wrote: I would suggest you check the current trunk (you can use a nightly build if you don't want to build yourself). There were some fixes in this are since 1.1. On Wed, May 29, 2013 at 6:56 AM, Ulrich Mayring u...@denic.de wrote: Hi all, please find attached an FO file and two PDFs, which were rendered from it. One was rendered by FOP 0.95, while the other was rendered by FOP 1.1. If you compare the PDFs, you'll see that the header Price (EUR) as well as the value 8,888,888.88 jut out to the right in the FOP 1.1 rendering, while they look fine in the FOP 0.95 output. The structure of the fo:table is such that the rightmost column is too small to fit either of these two items, so they have to overflow the table cell in some way (cut off is not an option here). In FOP 0.95 the items flow out to the left, practically into the previous table cell, but there is enough room to accommodate them. Whereas FOP 1.1 flows the items out to the right of the table cell, which in this case looks ugly. My questions are: can I get the old rendering behavior back? Perhaps by changing something in the FO? And who is actually doing the right thing, FOP 0.95 or FOP 1.1? Note: in FOP 1.1 these were rendered with the Complex Scripts feature off, so as to minimise variation between FOP 0.95 and 1.1. Many thanks in advance for any pointers, Ulrich --**--** - 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 - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 1.1: Rendering problem with overflowing table cells
Oh, and another thing: the new code depends on an unspecified trunk version of xmlgraphics-common. That makes it very hard to track bugs, as I might have another version than someone else. If no new release of xmlgraphics-common is available I would strongly suggest to depend on a specific nightly build, so that everyone downloading fop-trunk is on the same page with respect to external dependencies. Kind regards, Ulrich Ulrich Mayring wrote: Hello Luis, the problem with this approach is that not all setter-methods that were available in FopFactory are now available in the builder. Also, please note that the docs haven't been updated, they still suggest to do it the old way. For example, if you look at http://xmlgraphics.apache.org/fop/trunk/embedding.html#config-internal you'll find that the first two methods listed there are not available in the builder. Kind regards, Ulrich Luis Bernardo wrote: See this thread: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201302.mbox/%3c512d5b3c.8060...@gmail.com%3e On Wednesday, May 29, 2013, Ulrich Mayring wrote: Ooops, the newest Nightly Build has changed the Interface of FopFactory and FontManager. All the setter-methods in those classes are gone. How can I programmatically configure FOP now? The docs under http://xmlgraphics.apache.org/**fop/trunk/embedding.html#**config-internalhttp://xmlgraphics.apache.org/fop/trunk/embedding.html#config-internalstill suggest the old way. cheers, Ulrich Ulrich Mayring wrote: Hi Glenn, thanks for the pointer, your suspicion was correct. With the latest nightly build the page is rendered like it was in FOP 0.95, which I believe is the correct way. Thanks a lot, Ulrich Glenn Adams wrote: I would suggest you check the current trunk (you can use a nightly build if you don't want to build yourself). There were some fixes in this are since 1.1. On Wed, May 29, 2013 at 6:56 AM, Ulrich Mayring u...@denic.de wrote: Hi all, please find attached an FO file and two PDFs, which were rendered from it. One was rendered by FOP 0.95, while the other was rendered by FOP 1.1. If you compare the PDFs, you'll see that the header Price (EUR) as well as the value 8,888,888.88 jut out to the right in the FOP 1.1 rendering, while they look fine in the FOP 0.95 output. The structure of the fo:table is such that the rightmost column is too small to fit either of these two items, so they have to overflow the table cell in some way (cut off is not an option here). In FOP 0.95 the items flow out to the left, practically into the previous table cell, but there is enough room to accommodate them. Whereas FOP 1.1 flows the items out to the right of the table cell, which in this case looks ugly. My questions are: can I get the old rendering behavior back? Perhaps by changing something in the FO? And who is actually doing the right thing, FOP 0.95 or FOP 1.1? Note: in FOP 1.1 these were rendered with the Complex Scripts feature off, so as to minimise variation between FOP 0.95 and 1.1. Many thanks in advance for any pointers, Ulrich --**--** - 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 - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 1.1: Rendering problem with overflowing table cells
Ulrich, It is not uncommon for works under development (as is the case in the trunk) to depend on the latest version of a dependent JAR (e.g., xmlgraphics-commons). That's just the nature of the dev process. The same applies for the APIs and Docs. What you are asking for is appropriate for the next release (whatever number turns out to be applied), but is an ongoing process in the trunk. That's part of the risk/reward aspect of using an unreleased version. You have to spend more effort to use it, but you gain from its new features, fixes, etc. Regards, Glenn On Fri, May 31, 2013 at 1:36 AM, Ulrich Mayring u...@denic.de wrote: Oh, and another thing: the new code depends on an unspecified trunk version of xmlgraphics-common. That makes it very hard to track bugs, as I might have another version than someone else. If no new release of xmlgraphics-common is available I would strongly suggest to depend on a specific nightly build, so that everyone downloading fop-trunk is on the same page with respect to external dependencies. Kind regards, Ulrich Ulrich Mayring wrote: Hello Luis, the problem with this approach is that not all setter-methods that were available in FopFactory are now available in the builder. Also, please note that the docs haven't been updated, they still suggest to do it the old way. For example, if you look at http://xmlgraphics.apache.org/**fop/trunk/embedding.html#** config-internalhttp://xmlgraphics.apache.org/fop/trunk/embedding.html#config-internalyou'll find that the first two methods listed there are not available in the builder. Kind regards, Ulrich Luis Bernardo wrote: See this thread: http://mail-archives.apache.**org/mod_mbox/xmlgraphics-fop-** users/201302.mbox/%3c512D5B3C.**8060...@gmail.com%3ehttp://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/201302.mbox/%3c512d5b3c.8060...@gmail.com%3e On Wednesday, May 29, 2013, Ulrich Mayring wrote: Ooops, the newest Nightly Build has changed the Interface of FopFactory and FontManager. All the setter-methods in those classes are gone. How can I programmatically configure FOP now? The docs under http://xmlgraphics.apache.org/fop/trunk/embedding.html# config-internalhttp://xmlgraphics.apache.org/**fop/trunk/embedding.html#**config-internal http://**xmlgraphics.apache.org/fop/**trunk/embedding.html#config-** internalhttp://xmlgraphics.apache.org/fop/trunk/embedding.html#config-internal still suggest the old way. cheers, Ulrich Ulrich Mayring wrote: Hi Glenn, thanks for the pointer, your suspicion was correct. With the latest nightly build the page is rendered like it was in FOP 0.95, which I believe is the correct way. Thanks a lot, Ulrich Glenn Adams wrote: I would suggest you check the current trunk (you can use a nightly build if you don't want to build yourself). There were some fixes in this are since 1.1. On Wed, May 29, 2013 at 6:56 AM, Ulrich Mayring u...@denic.de wrote: Hi all, please find attached an FO file and two PDFs, which were rendered from it. One was rendered by FOP 0.95, while the other was rendered by FOP 1.1. If you compare the PDFs, you'll see that the header Price (EUR) as well as the value 8,888,888.88 jut out to the right in the FOP 1.1 rendering, while they look fine in the FOP 0.95 output. The structure of the fo:table is such that the rightmost column is too small to fit either of these two items, so they have to overflow the table cell in some way (cut off is not an option here). In FOP 0.95 the items flow out to the left, practically into the previous table cell, but there is enough room to accommodate them. Whereas FOP 1.1 flows the items out to the right of the table cell, which in this case looks ugly. My questions are: can I get the old rendering behavior back? Perhaps by changing something in the FO? And who is actually doing the right thing, FOP 0.95 or FOP 1.1? Note: in FOP 1.1 these were rendered with the Complex Scripts feature off, so as to minimise variation between FOP 0.95 and 1.1. Many thanks in advance for any pointers, Ulrich --**--** - To unsubscribe, e-mail: fop-users-unsubscribe@** xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-help@xmlgraphics.** apache.org fop-users-h...@xmlgraphics.apache.org --** --**- To unsubscribe, e-mail: fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-help@xmlgraphics.** apache.org fop-users-h...@xmlgraphics.apache.org --**--**- To unsubscribe, e-mail: fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
Re: reduce size of PDF generated with FOP
An image is only embedded once in PDF if you always refer to it by the same URI, no matter how many times you refer to it. So I don't think that is the issue. Can you send an simple example of a PDF with just an image generated by Framemaker and by FOP so that we can investigate the difference. On 5/30/13, chandone echan...@yahoo.com wrote: Hello everyone, I use Java, XSL-FO and FOP to generate PDFs that consist in one or more pages of data and images, each page having a header and a footer containing images themselves. These header and footer are repeated on each and every page of the PDF documents. The images are responsible for a large part of the size of the resulting PDF (about 50 %). I noticed that, by converting them from JPEG to TIFF, and by reducing their resolution, I was able to reduce considerably the size of the PDF as well. But I now have the feeling that I have reached a dead-end as far as images as concerned. The PDFs are still very huge, compared to those that used to be generated with FrameMaker, the Adobe PDF generation system that we're willing to get rid of. And I'm sorry to say that I can't think of another way to reduce the PDFs' size, as the Web mainly talks about pre-processing images in order to make PDFs smaller. I was wondering whether, maybe, it would be possible in a way or another to tell FOP to repeat the images in all headers and footers in some kind of way so that the images would be embedded only once in the document and just mirrored on the other pages. Plus, there ought to be other ways to reduce the PDF size, apart from images, don't you think? I would highly appreciate any advice on this topic. Thanks a lot in advance for your time and help. Erwann -- View this message in context: http://apache-fop.1065347.n5.nabble.com/reduce-size-of-PDF-generated-with-FOP-tp38619.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 - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Conversion of PDF to Postscript Compatible Asset
Can you sends us the original example so that we can take a look? There have been many recent fixes regarding fop-pdf-images and pdfbox and issues related to images. But we are aware of bugs in pdfbox that we haven't investigated, let alone addressed... If the shading that you describe is due to transparency then that may be part of the problem. PostScript does not support transparency the way PDF does, so what pdfbox does is to build a composite where the color of a pixel is a blend of the foregroung and background colors but the result is not always correct (probably due to bugs). On 5/30/13, Martin Edge martin.e...@intellimail.com.au wrote: Hi Guys, Wondering if you could suggest whether I should bother and if so where I would start isolating the root cause of this problem. I'm using fop-pdf-images as a background, and in PDF it looks fine, in postscript the shading part of the document falls off. (I've tried both CMYK based and RGB based PDFs with it.) I ended up having to render the document as PDF, which removes a lot of the smarts I have in place in respects to duplexing and tray selection. I'm currently using FOP 1.1 for the process, with pdf-image add-in - I have re-downloaded the fop 1.1 source and the latest fop-pdf-images and compiled them and it seems to have built OK. The only output which seems PDFBox related is: May 30, 2013 2:57:10 PM org.apache.pdfbox.util.PDFStreamEngine processOperator INFO: unsupported/disabled operation: BDC May 30, 2013 2:57:11 PM org.apache.pdfbox.util.PDFStreamEngine processOperator INFO: unsupported/disabled operation: BX May 30, 2013 2:57:11 PM org.apache.pdfbox.util.PDFStreamEngine processOperator INFO: unsupported/disabled operation: EX May 30, 2013 2:57:11 PM org.apache.pdfbox.util.PDFStreamEngine processOperator INFO: unsupported/disabled operation: EMC I have built a mini test case/example if that helps or if anyone is curious.. Thanks Martin. IntelliMail - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
