DO NOT REPLY [Bug 40425] - PNG - Cannot read image dimensions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40425. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40425 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2006-09-10 11:43 --- Looks like a bug in the PNG codec for JDK 1.4.2_11 then. It may be this bug here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4826548 As a work-around on JDK 1.4.2, you can change org.apache.fop.image.ImageFactory. Find the line: imt = new ImageMimeType(image/png); ...and change the block there to this: imt = new ImageMimeType(image/png); imageMimeTypes.put(imt.getMimeType(), imt); imt.addProvider(pngImage); imt.addProvider(imageIoImage); This gives the internal PNG codec a higher priority over the ImageIO codec. (In reply to comment #3) Right, running FOP with JDK 1.5 works :-) Building and running FOP using JDK 1.4.2_11 with the latest sources form the SVN trunk, I get the following backtrace. The build proceeds, though, resulting in a PDF document missing that image (which in fact is a black square to simplify matters). 07.09.2006 10:10:09 org.apache.fop.image.ImageIOImage loadBitmap SCHWERWIEGEND: Error while loading image: 4 java.lang.ArrayIndexOutOfBoundsException: 4 at com.sun.imageio.plugins.png.PNGImageReader.parse_PLTE_chunk(PNGImageReader.java:347) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Configuration file problems
Ok, I consider myself defeated concerning the way we handle the configuration file (See recent threads on fop-users). The Avalon configuration approach is very nice for the developer but obviously bullshit in terms of end-user-friendlyness. The attempt to overlay the configuration layout with an XSD is generally a good idea but with the current configuration layout, it's not a workable solution. If anyone has a good plan to improve the situation, I'm all ears. I think the configuration file needs to be built based on an XML Schema and FOP should by default validate the configuration file (hard-coded in FOP) so the users get proper feedback if they try to feed FOP with an invalid format. But that means the XML Schema must be water-tight. On the other side, we will probably lose extensibility of the configuration file format. When someone adds his own renderer, for example, he can't just have his own config values because he can't change the XML Schema. So that may mean we probably can't use XML Schema to validate the file. But then, maybe we can define the individual renderer config parts as xsd:any or something like that and let each renderer validate its own configuration (either manually or using an XSD). ATM, I can't think of a good solution but apparently, we need to change something at some point. Any ideas, thoughts? Jeremias Maerki
Re: Configuration file problems
On Sunday 10 September 2006 20:52, Jeremias Maerki wrote: Ok, I consider myself defeated concerning the way we handle the configuration file (See recent threads on fop-users). The Avalon configuration approach is very nice for the developer but obviously bullshit in terms of end-user-friendlyness. The attempt to overlay the configuration layout with an XSD is generally a good idea but with the current configuration layout, it's not a workable solution. Not sure I agree with the bleak picture you are painting. In my assessment most problems seem to be caused by the change of config format from 0.20.5 to 0.9x. Not by the format itself. What about having a command line option which triggers a config file validation. Similar to Apache HTTPD: apachectl -t Run a configuration file syntax test. It parses the configura- tion files and either reports Syntax Ok or detailed information about the particular syntax error. Manuel If anyone has a good plan to improve the situation, I'm all ears. I think the configuration file needs to be built based on an XML Schema and FOP should by default validate the configuration file (hard-coded in FOP) so the users get proper feedback if they try to feed FOP with an invalid format. But that means the XML Schema must be water-tight. On the other side, we will probably lose extensibility of the configuration file format. When someone adds his own renderer, for example, he can't just have his own config values because he can't change the XML Schema. So that may mean we probably can't use XML Schema to validate the file. But then, maybe we can define the individual renderer config parts as xsd:any or something like that and let each renderer validate its own configuration (either manually or using an XSD). ATM, I can't think of a good solution but apparently, we need to change something at some point. Any ideas, thoughts? Jeremias Maerki
Re: Configuration file problems
Ok, but with your statement you're carefully avoiding the topic about how to actually validate the configuration. Are we then writing a number of plug-ins which contain manually written code that verifies the config file on the various levels (root, renderer, fonts)? Possible, not difficult but takes quite a bit of work to get done. On 10.09.2006 16:03:06 Manuel Mall wrote: On Sunday 10 September 2006 20:52, Jeremias Maerki wrote: Ok, I consider myself defeated concerning the way we handle the configuration file (See recent threads on fop-users). The Avalon configuration approach is very nice for the developer but obviously bullshit in terms of end-user-friendlyness. The attempt to overlay the configuration layout with an XSD is generally a good idea but with the current configuration layout, it's not a workable solution. Not sure I agree with the bleak picture you are painting. In my assessment most problems seem to be caused by the change of config format from 0.20.5 to 0.9x. Not by the format itself. What about having a command line option which triggers a config file validation. Similar to Apache HTTPD: apachectl -t Run a configuration file syntax test. It parses the configura- tion files and either reports Syntax Ok or detailed information about the particular syntax error. Manuel If anyone has a good plan to improve the situation, I'm all ears. I think the configuration file needs to be built based on an XML Schema and FOP should by default validate the configuration file (hard-coded in FOP) so the users get proper feedback if they try to feed FOP with an invalid format. But that means the XML Schema must be water-tight. On the other side, we will probably lose extensibility of the configuration file format. When someone adds his own renderer, for example, he can't just have his own config values because he can't change the XML Schema. So that may mean we probably can't use XML Schema to validate the file. But then, maybe we can define the individual renderer config parts as xsd:any or something like that and let each renderer validate its own configuration (either manually or using an XSD). ATM, I can't think of a good solution but apparently, we need to change something at some point. Any ideas, thoughts? Jeremias Maerki Jeremias Maerki
Re: Re: Configuration file problems
We could just identify the schema in the DOCTYPE (or DTD if we decide to go that route--a schema is much more powerful, but isn't it more overhead?). Then, we could alter the location at will. Instead of embedding the file in FOP, it could be located either locally (relative to FOP or the XML files), or it could be located on a remote server. As for validating, when someone creates a plug-in (or updates FOP to handle some new, configurable feature), one portion of the PATCH would update the fop-config.xsd file. On a related point, does it make sense that all configuration be handled in one place (e.g., fonts too)? Clay -- Regards, The Web Maestro -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: Configuration file problems
On 10.09.2006 17:01:30 The Web Maestro wrote: We could just identify the schema in the DOCTYPE (or DTD if we decide to go that route--a schema is much more powerful, but isn't it more overhead?). Then, we could alter the location at will. Instead of embedding the file in FOP, it could be located either locally (relative to FOP or the XML files), or it could be located on a remote server. Locating or specifying a DTD or an XML Schema is not the issue. We already have an XML Schema we can use but XML Schema is not expressive enough to properly validate the current configuration XML. As for validating, when someone creates a plug-in (or updates FOP to handle some new, configurable feature), one portion of the PATCH would update the fop-config.xsd file. It's possible to assemble an ad-hoc XML Schema using the import feature as needed (Renderers would contribute a sub-schema, for example), but again, XML Schema is not expressive enough for the current format (distinction of a single element type by a type attribute, e.g. renderer). The problem with the ad-hoc schema is that it's not feasible for validation in an XML editor, only during FOP runtime. On a related point, does it make sense that all configuration be handled in one place (e.g., fonts too)? Can you explain further what you mean? Jeremias Maerki
Re: Re: Configuration file problems
On 9/10/06, Jeremias Maerki [EMAIL PROTECTED] wrote: On 10.09.2006 17:01:30 The Web Maestro wrote: On a related point, does it make sense that all configuration be handled in one place (e.g., fonts too)? Can you explain further what you mean? Sorry. For some reason I thought the FONT configuration was in a different spot from normal FOP config. I re-read the FOP Config[1] the FONT configuration[2] sections again, and realized I was confusing the PostScript TrueType metrics file generation process with FOP's configuration file. Never mind! [1] FOP Configuration: http://xmlgraphics.apache.org/fop/0.92/configuration.html [2] FOP Fonts Configuration: http://xmlgraphics.apache.org/fop/0.92/fonts.html -- Regards, The Web Maestro -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
