DO NOT REPLY [Bug 47781] GRAVE: Exception: java.lang.NullPointerException when unsing fop
https://issues.apache.org/bugzilla/show_bug.cgi?id=47781 Vincent Hennebert vhenneb...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Vincent Hennebert vhenneb...@gmail.com 2009-10-16 03:22:46 UTC --- Closing this bug as the issue does no longer appear in Trunk. Feel free to re-open it if you can reproduce it with the Trunk. (To download and build a version of the Trunk, see here: http://xmlgraphics.apache.org/fop/download.html#source http://xmlgraphics.apache.org/fop/trunk/compiling.html ) Vincent -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48003] [PATCH] Improved variable names around Kerning and KnuthElement
https://issues.apache.org/bugzilla/show_bug.cgi?id=48003 --- Comment #2 from Alexander Kiel alexanderk...@gmx.net 2009-10-16 05:07:53 UTC --- Thanks for applying my patch. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
OutOfMemoryError on IntermediateFormatTestSuite
Hi, I've got an OutOfMemoryError running IntermediateFormatTestSuite on the FOP trunk ( Rev ID : 825646 ) junit-intermediate-format: [echo] Running intermediate format tests... [junit] Testsuite: org.apache.fop.intermediate.IntermediateFormatTestSuite [junit] Exception in thread main java.lang.OutOfMemoryError: Java heap space [junit] Test org.apache.fop.intermediate.IntermediateFormatTestSuite FAILED (crashed) All others test suites are Ok ... Is there something special for this test suite ? Am I the only one to have this error ? What is the last revision ID which pass all tests ?
Re: When is PDFImageHandlerGraphics2D used?
Hi Jeremias, Thanks for the hint. I tried with a WMF image and found out that this class is used by both the renderer and the painter. I’ve just implemented accessibility support in it. Vincent Jeremias Maerki wrote: And you can use a WMF (Windows Metafile) file. See org.apache.fop.image.loader.batik.ImageConverterWMF2G2D.java On 15.10.2009 18:30:46 Jeremias Maerki wrote: Hi Vincent That would be Barcode4J, for example. If the latest code from Barcode4J's CVS HEAD is used, ImageConverters get registered. One of those can convert Barcode XML to Graphics2D which should be picked over the Barcode XML - SVG implementation in the PDF case. But that will only be triggered with the new IF. With the renderer, I assume (without checking) the XMLHandler interface will be used. On 15.10.2009 17:51:01 Vincent Hennebert wrote: Hi, I tried every image format I could think of, none triggers the use of PDFImageHandlerGraphics2D. AFAIU this is the only image handler that doesn’t call PDFRenderer.placeImage or renderDocument in return, in which accessibility is handled. So if that handler is used the generated PDF will be invalid. What type of images is that handler used for? Thanks, Vincent Jeremias Maerki Jeremias Maerki
Re: Making AFPPaintingState singleton
Hi Adrian, Thanks for your reply. Yes, You are absolutely right, I am trying to handle these conversions at the renderer level... I will soon come out with a patch to the bug you opened. Thanks once again for the source points, Venkat. Adrian Cumiskey wrote: Hi Venkat, This approach is not a good idea. It is possible that a runtime environment is configured to have multiple instances of Fop being instantiated by FopFactory with different rendering configurations (e.g. renderer resolution values). Its disappointing, but I've just noticed a bug in AFPPageOverlayElement, an AFPPaintingState shouldn't just be instantiated in there like that. The processNode implementation will not accurately calculate and plot the page overlay position if the document resolution is different from the detault value of 240dpi. This calculation should be carried out much later at rendering time, *not* in here at configuration time - its very hacky and you'll need to refactor this. I seem to remember that Chris worked on this new feature so you may want to converse with him about its implementation. Adrian. Venkat Reddy wrote: Hi, AFPPaintingState is being used in three different places altogether in FopTrunk source. The default constructor is being used in the following three classes... 1. AFPDocumentHandler.java 2. AFPRenderer.java 3. AFPPageOverlayElement.java There is a variable 'resolution' is being initialized for each instance, this resolution parameter can be set using the 'fop.xconf' for a particular render... Ex:- AFPRenderer configuration below renderer mime=application/x-afp !-- The bit depth and type of images produced (this is the default setting) -- images mode=b+w bits-per-pixel=8/ renderer-resolution1400/renderer-resolution The above renderer-resolution is being hardcoded as '240dpi' in AFPRendererConfigurator.java, which initiates the renderer resolution based on the configuration set in 'fop.xconf'. In order to resolve this problem, I will be changing the AFPPaintingState as singleton, so that all the above classes will get the instance using 'getInstance()' method instead of default constructor. This will resolve the renderer-resolution problem as well, by a simple change in AFPRendererConfigurator (instead of hardcoded value 240, assigning the value from the configuration object). Please review the above changes and tell me, if I am doing anything wrong here? Thanks, Venkat.
Re: Making AFPPaintingState singleton
Hi Venkat, I advise you to just pass the bare values in AFPPageOverlayElement from attlist.getValue(ATT_X) and attlist.getValue(ATT_Y) through to the AFPPageOverlay and remove the use of AFPPaintingState and AFPUnitConverter in there - this was never the correct place to do this. You could look at calling upon AFPUnitConverter to carry out the correct plotting calculation on your AFPPaintingState instance member variable in DataStream.createIncludePageOverlay(String name, int x, int y). This would mean regardless of whether FOP is using the AFPDocumentHandler or the AFPRenderer implementation, the calculation will still be done correctly and at the right time. Hope this helps you with the fix. Adrian. Venkat Reddy wrote: Hi Adrian, Thanks for your reply. Yes, You are absolutely right, I am trying to handle these conversions at the renderer level... I will soon come out with a patch to the bug you opened. Thanks once again for the source points, Venkat. Adrian Cumiskey wrote: Hi Venkat, This approach is not a good idea. It is possible that a runtime environment is configured to have multiple instances of Fop being instantiated by FopFactory with different rendering configurations (e.g. renderer resolution values). Its disappointing, but I've just noticed a bug in AFPPageOverlayElement, an AFPPaintingState shouldn't just be instantiated in there like that. The processNode implementation will not accurately calculate and plot the page overlay position if the document resolution is different from the detault value of 240dpi. This calculation should be carried out much later at rendering time, *not* in here at configuration time - its very hacky and you'll need to refactor this. I seem to remember that Chris worked on this new feature so you may want to converse with him about its implementation. Adrian. Venkat Reddy wrote: Hi, AFPPaintingState is being used in three different places altogether in FopTrunk source. The default constructor is being used in the following three classes... 1. AFPDocumentHandler.java 2. AFPRenderer.java 3. AFPPageOverlayElement.java There is a variable 'resolution' is being initialized for each instance, this resolution parameter can be set using the 'fop.xconf' for a particular render... Ex:- AFPRenderer configuration below renderer mime=application/x-afp !-- The bit depth and type of images produced (this is the default setting) -- images mode=b+w bits-per-pixel=8/ renderer-resolution1400/renderer-resolution The above renderer-resolution is being hardcoded as '240dpi' in AFPRendererConfigurator.java, which initiates the renderer resolution based on the configuration set in 'fop.xconf'. In order to resolve this problem, I will be changing the AFPPaintingState as singleton, so that all the above classes will get the instance using 'getInstance()' method instead of default constructor. This will resolve the renderer-resolution problem as well, by a simple change in AFPRendererConfigurator (instead of hardcoded value 240, assigning the value from the configuration object). Please review the above changes and tell me, if I am doing anything wrong here? Thanks, Venkat.
checkstyle changes in the build
I do not like this style of only using tools in FOP's own tools directory:
condition property=checkstyle.avail
and
available classname=com.puppycrawl.tools.checkstyle.CheckStyleTask
classpath
path refid=libs-build-tools-classpath/
/classpath
/available
available file=${checkstyle.noframes.xslt}/
/and
/condition
Previous versions of build.xml allowed me to use the Debian provided
jar files:
checkstyle.home.dir=/usr/share/java
property name=checkstyle.lib value=${checkstyle.home.dir}/
path id=libs-checkstyle
fileset dir=${checkstyle.lib}
include name=*.jar/
/fileset
/path
I would like to see this possibility restored.
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
DO NOT REPLY [Bug 48013] New: Image processing makes FOP really slow
https://issues.apache.org/bugzilla/show_bug.cgi?id=48013 Summary: Image processing makes FOP really slow Product: Fop Version: 0.95 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: levin...@intersystems.com Created an attachment (id=24385) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24385) image testing file In investigating a problem in the display of PNG images in FOP, I discovered that image processing was really slow. Examining the code in a debugger the surprise is that the source of slowness is not the rendering of the image (which is done through Java’s JAI) but in the steps leading up to the rendering of the image. For a simple FO page, with a single PNG image FOP takes 90 seconds. Remove the image and FOP takes 1 second. RenderX takes a second as well with our without the image. So the addition of a single image to an FO page results in extreme slowness – two orders of magnitude slower than RenderX XEP. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48013] Image processing makes FOP really slow
https://issues.apache.org/bugzilla/show_bug.cgi?id=48013 --- Comment #1 from Jonathan Levinson levin...@intersystems.com 2009-10-16 11:44:41 UTC --- Created an attachment (id=24386) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24386) Image used Image used -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
