Making AFPPaintingState singleton
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.
When is PDFImageHandlerGraphics2D used?
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
Re: Making AFPPaintingState singleton
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: When is PDFImageHandlerGraphics2D used?
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
DO NOT REPLY [Bug 48002] New: AFP plot values are incorrectly calculated in page overlays when renderer-resolution setting not 240dpi
https://issues.apache.org/bugzilla/show_bug.cgi?id=48002 Summary: AFP plot values are incorrectly calculated in page overlays when renderer-resolution setting not 240dpi Product: Fop Version: 1.0dev Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: d...@cumiskey.com Plot values for AFP page overlays are always calculated at a resolution of 240dpi regardless of configuration settings. This calculation should be done at rendering time - not during configuration (See http://markmail.org/search/?q=fop-dev#query:fop-dev%20order%3Adate-backward+page:1+mid:6xesm7i7jkwiozjg+state:results) for details. Adrian. -- 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] New: [PATCH] Improved variable names around Kerning and KnuthElement
https://issues.apache.org/bugzilla/show_bug.cgi?id=48003 Summary: [PATCH] Improved variable names around Kerning and KnuthElement Product: Fop Version: all Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: alexanderk...@gmx.net Created an attachment (id=24381) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24381) patch file Just some small things from me to start with something that can applied separately. - improved variable names around Kerning and KnuthElement - changed Font#getKerningValue(char, char) to return the value in pt instead of milliem The most critical change is that of Font#getKerningValue(char, char). Can someone check, that nobody else except TextLayoutManager uses it? -- 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 Adrian Cumiskey d...@cumiskey.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Adrian Cumiskey d...@cumiskey.com 2009-10-15 13:47:57 UTC --- Patch applied to trunk. Thanks for the improving the readability of what is a complex area of FOP. It should not be underestimated how valuable these kind of patches are to the health of the project. Its unselfish work, much appreciated and very good to see :). Adrian. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
