Re: FOP 1.0 - LengthRangeProperty checkConsistency
On Wed, Jan 12, 2011 at 05:35:28PM -0500, Benoit, Frederick C. wrote: I am using StylusStudio which the Xalan processor, FOP 1.0 validation XSD and FOP 1.0 post-processor to render a PDF. I've been working my way through various validation errors over the past few days, but now I'm stuck on the following error: org.apache.fop.fo.properties.LengthRangeProperty checkConsistency SEVERE: forcing opt to min in LengthRange You have an optimum value that is less than the minimum value, and both were set explicitly. Simon - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP Trunk Snapshot (fop-20110110.jar) : barcode4j
Why does this cause an error? I see no problem in barcode's method BarcodeElementMapping.initialize. In eclipse I can compile barcode without errors with FOP from before your latest fix. Simon On Wed, Jan 12, 2011 at 09:01:45PM +0100, Jeremias Maerki wrote: Thanks for noticing. This was broken by: http://svn.apache.org/viewvc?rev=1055034view=rev ...and is now fixed by: http://svn.apache.org/viewvc?rev=1058295view=rev There was a comment there saying not to change HashMap to Map, but it seems it got overlooked. On 12.01.2011 12:06:03 Philippe Pithon wrote: Hi, I use now FOP Trunk Snapshot (20110110) and barcode4j-fop-ext-complete.jar With FOP 1.0, barcode works fine but in trunk, there is an error Any ideas ? Philippe Pithon Caused by: java.lang.NoSuchFieldError: foObjs at org.krysalis.barcode4j.fop.BarcodeElementMapping.initialize(BarcodeElementMapping.java:49) at org.krysalis.barcode4j.fop.BarcodeElementMapping.init(BarcodeElementMapping.java:39) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.apache.fop.fo.ElementMappingRegistry.addElementMapping(ElementMappingRegistry.java:97) at org.apache.fop.fo.ElementMappingRegistry.setupDefaultMappings(ElementMappingRegistry.java:80) at org.apache.fop.fo.ElementMappingRegistry.init(ElementMappingRegistry.java:67) at org.apache.fop.apps.FopFactory.init(FopFactory.java:162) at org.apache.fop.apps.FopFactory.newInstance(FopFactory.java:185) - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP Trunk Snapshot (fop-20110110.jar) : barcode4j
Yes, you can probably recompile, but the change violated binary backwards-compatibility. I've put the comment there precisely because of that reason. I've had to revert the same change once before. On 13.01.2011 11:01:15 Simon Pepping wrote: Why does this cause an error? I see no problem in barcode's method BarcodeElementMapping.initialize. In eclipse I can compile barcode without errors with FOP from before your latest fix. Simon On Wed, Jan 12, 2011 at 09:01:45PM +0100, Jeremias Maerki wrote: Thanks for noticing. This was broken by: http://svn.apache.org/viewvc?rev=1055034view=rev ...and is now fixed by: http://svn.apache.org/viewvc?rev=1058295view=rev There was a comment there saying not to change HashMap to Map, but it seems it got overlooked. On 12.01.2011 12:06:03 Philippe Pithon wrote: Hi, I use now FOP Trunk Snapshot (20110110) and barcode4j-fop-ext-complete.jar With FOP 1.0, barcode works fine but in trunk, there is an error Any ideas ? Philippe Pithon Caused by: java.lang.NoSuchFieldError: foObjs at org.krysalis.barcode4j.fop.BarcodeElementMapping.initialize(BarcodeElementMapping.java:49) at org.krysalis.barcode4j.fop.BarcodeElementMapping.init(BarcodeElementMapping.java:39) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.apache.fop.fo.ElementMappingRegistry.addElementMapping(ElementMappingRegistry.java:97) at org.apache.fop.fo.ElementMappingRegistry.setupDefaultMappings(ElementMappingRegistry.java:80) at org.apache.fop.fo.ElementMappingRegistry.init(ElementMappingRegistry.java:67) at org.apache.fop.apps.FopFactory.init(FopFactory.java:162) at org.apache.fop.apps.FopFactory.newInstance(FopFactory.java:185) Jeremias Maerki - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Antialising issue with borders in PDF with fop-0.95
Hi, when generating a table in PDF with FOP and XML the borders of the table appear in different width on the Screen (even with different PDF viewers!). I was searching the web and this forum and found the following Question in this forum: http://old.nabble.com/Rows-borders-look-so-bad...-td24715165.html In this thread john farrow wrote: What you are seeing is Acrobat anti-aliasing some parts of the border and not others. You can turn off anti-aliasing in Acrobat to make this go away (on your machine), otherwise FOP needs to be fixed to remove the problem. The problem occurs because some parts of the border are drawn using filled shapes and some are drawn using solid lines. Acrobat applies anti-aliasing to one type of rendering and not the other. This is also my issue. This is my table at 100% in Acrobat Reader: http://old.nabble.com/file/p30661446/FOP_100.png FOP_100.png When looking at 400% at this image in gimp it is clearly visible, that the different borders are handled with different antialiasing: http://old.nabble.com/file/p30661446/FOP_100_400.png FOP_100_400.png Is there a patch available for FOP to solve this problem? Or is it possible to disable antialiasing from within XML or Java for borders? If that is possible, can you tell me how it is done. I couldn't find any reference for this at the web. From my point of view FOP should draw all lines of a table in the same way, not sometimes as filled shapes and sometimes as solid lines. Otherwise it is not possible to generate high quality tables with FOP! Best regards, Juergen -- View this message in context: http://old.nabble.com/Antialising-issue-with-borders-in-PDF-with-fop-0.95-tp30661446p30661446.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: Rendering differences: fop-0.95 vs fop.-1.0
On 01/12/2011 05:43 AM, Vincent Hennebert wrote: Hi Rob, On 11/01/11 13:20, Rob Sargent wrote: I've proven to myself that I'm generating identical xml, but getting malformed pdf in version 1.0 where 0.95 was perfectly happy. I'm getting some clipping along the inner (left) side of right-hand pages in static region-before but only on some pages. Not all pages, however. It looks as if I've over-lain a high-precedence region-start but it's not in my code :) Like on page 3? This is a known bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=49910 The workaround is to set the overflow property, on the corresponding fo:region-before element, to visible. Or unset it completely (that is, leave it to its default value). Has anyone seen anything like this? Attaching the fo.xml for anyone that's curious. Thanks, rjs By removing the overflow=hidden directive in the region-before both revs are producing beautiful (imho) output. I can live with the smashed text blocks when there is too much in the region-before. It's all manually reviewed rather frequently. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Rendering differences: fop-0.95 vs fop.-1.0
On 01/13/2011 11:42 AM, Rob Sargent wrote: On 01/12/2011 05:43 AM, Vincent Hennebert wrote: Hi Rob, On 11/01/11 13:20, Rob Sargent wrote: I've proven to myself that I'm generating identical xml, but getting malformed pdf in version 1.0 where 0.95 was perfectly happy. I'm getting some clipping along the inner (left) side of right-hand pages in static region-before but only on some pages. Not all pages, however. It looks as if I've over-lain a high-precedence region-start but it's not in my code :) Like on page 3? This is a known bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=49910 The workaround is to set the overflow property, on the corresponding fo:region-before element, to visible. Or unset it completely (that is, leave it to its default value). Has anyone seen anything like this? Attaching the fo.xml for anyone that's curious. Thanks, rjs By removing the overflow=hidden directive in the region-before both revs are producing beautiful (imho) output. I can live with the smashed text blocks when there is too much in the region-before. It's all manually reviewed rather frequently. Oops. spoke to soon. Have more work to do. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Antialising issue with borders in PDF with fop-0.95
Hi Juergen, What does a print of the pdf look like? It may be the viewer (as mentioned in the post you referenced) that is responsible for anti-aliasing the pdf for screen display, and may not be a good representation of the print. Currently FOP draw each of the 4 border sections of a cell separately, even when they should combine to form a continuous mark - likewise for the neighbouring cells of a table. Borders are represented as vector drawing commands in a graphical stream within the PDF and the resolution of this drawing space is 1 millipoint - 1/1000th of 1/72th of an inch. The drawing commands are directly generated by fop from the representation of the border - no intermediate Java2D - rasterisation process occurs, and so antialiasing is not an inherent problem in the process. I hope this helps, Pete On Thu, Jan 13, 2011 at 11:49 AM, Juergen Birkle juergen.bir...@doubleslash.de wrote: Hi, when generating a table in PDF with FOP and XML the borders of the table appear in different width on the Screen (even with different PDF viewers!). I was searching the web and this forum and found the following Question in this forum: http://old.nabble.com/Rows-borders-look-so-bad...-td24715165.html In this thread john farrow wrote: What you are seeing is Acrobat anti-aliasing some parts of the border and not others. You can turn off anti-aliasing in Acrobat to make this go away (on your machine), otherwise FOP needs to be fixed to remove the problem. The problem occurs because some parts of the border are drawn using filled shapes and some are drawn using solid lines. Acrobat applies anti-aliasing to one type of rendering and not the other. This is also my issue. This is my table at 100% in Acrobat Reader: http://old.nabble.com/file/p30661446/FOP_100.png FOP_100.png When looking at 400% at this image in gimp it is clearly visible, that the different borders are handled with different antialiasing: http://old.nabble.com/file/p30661446/FOP_100_400.png FOP_100_400.png Is there a patch available for FOP to solve this problem? Or is it possible to disable antialiasing from within XML or Java for borders? If that is possible, can you tell me how it is done. I couldn't find any reference for this at the web. From my point of view FOP should draw all lines of a table in the same way, not sometimes as filled shapes and sometimes as solid lines. Otherwise it is not possible to generate high quality tables with FOP! Best regards, Juergen -- View this message in context: http://old.nabble.com/Antialising-issue-with-borders-in-PDF-with-fop-0.95-tp30661446p30661446.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: Rendering differences: fop-0.95 vs fop.-1.0
On 01/13/2011 11:44 AM, Rob Sargent wrote: On 01/13/2011 11:42 AM, Rob Sargent wrote: On 01/12/2011 05:43 AM, Vincent Hennebert wrote: Hi Rob, On 11/01/11 13:20, Rob Sargent wrote: I've proven to myself that I'm generating identical xml, but getting malformed pdf in version 1.0 where 0.95 was perfectly happy. I'm getting some clipping along the inner (left) side of right-hand pages in static region-before but only on some pages. Not all pages, however. It looks as if I've over-lain a high-precedence region-start but it's not in my code :) Like on page 3? This is a known bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=49910 The workaround is to set the overflow property, on the corresponding fo:region-before element, to visible. Or unset it completely (that is, leave it to its default value). Has anyone seen anything like this? Attaching the fo.xml for anyone that's curious. Thanks, rjs By removing the overflow=hidden directive in the region-before both revs are producing beautiful (imho) output. I can live with the smashed text blocks when there is too much in the region-before. It's all manually reviewed rather frequently. Oops. spoke to soon. Have more work to do. Once I removed /all/ the overflows, things appear fine.
