Re: external-graphics supported formats
DummyConnection triggers an unpleasant memory. Look here: http://issues.apache.org/bugzilla/show_bug.cgi?id=33383 So, no, unfortunately, no ideas from this time. :-( On 09.08.2005 17:26:04 Manuel Mall wrote: > On Tue, 9 Aug 2005 08:15 pm, Jeremias Maerki wrote: > > On 09.08.2005 13:57:09 Manuel Mall wrote: > > > On Tue, 9 Aug 2005 06:21 pm, Jeremias Maerki wrote: > > > > On 09.08.2005 11:55:55 Manuel Mall wrote: > > > > > > > > > BMP and GIF cause > > > > > exceptions. > > > > > > > > That's not so good. > > > > > > I'll investigate this. > > > > Thanks again. > > Spent the last couple of hours to get to the bottom of the GIF problem. > Here is the stackdump: > Uncaught error fetching image: > java.lang.NullPointerException > at > sun.awt.image.URLImageSource.getConnection(URLImageSource.java:97) > at > sun.awt.image.URLImageSource.getDecoder(URLImageSource.java:106) > at > sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:240) > at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:172) > at sun.awt.image.ImageFetcher.run(ImageFetcher.java:136) > > That's it as it happens in a separate thread. The application then > appears to hang as the main thread seems to wait for some signal from > the image loading thread that it has completed. Now all this is JDK > dependent! Java 1.4 works fine but Java 5.0 => Null Pointer Exception. > It has to do with the GifImage.DummyConnection class. It pass null as > the URL argument to its superclass constructor and it is that null URL > which is causing the NPE. Why doesn't it happen with JDK 1.4? Not sure, > but URLImageSource.getConnection will return the existing connection > the first time its called and reestablish the connection the 2nd time > its called. Under JDK 1.4 its appears to be called only once. > > To fix this I need to give the constructor the proper URL of the image > but this is not available within the class. I am reluctant to change > all the interfaces, which would affect all image handlers, to carry the > URL as well as the InputStream just for this problem which is specific > to GIF. > > Any one out there with some ideas here? > > Thanks > > Manuel > > > > Jeremias Maerki Jeremias Maerki
Re: external-graphics supported formats
On Tue, 9 Aug 2005 08:15 pm, Jeremias Maerki wrote: > On 09.08.2005 13:57:09 Manuel Mall wrote: > > On Tue, 9 Aug 2005 06:21 pm, Jeremias Maerki wrote: > > > On 09.08.2005 11:55:55 Manuel Mall wrote: > > > > > > BMP and GIF cause > > > > exceptions. > > > > > > That's not so good. > > > > I'll investigate this. > > Thanks again. Spent the last couple of hours to get to the bottom of the GIF problem. Here is the stackdump: Uncaught error fetching image: java.lang.NullPointerException at sun.awt.image.URLImageSource.getConnection(URLImageSource.java:97) at sun.awt.image.URLImageSource.getDecoder(URLImageSource.java:106) at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:240) at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:172) at sun.awt.image.ImageFetcher.run(ImageFetcher.java:136) That's it as it happens in a separate thread. The application then appears to hang as the main thread seems to wait for some signal from the image loading thread that it has completed. Now all this is JDK dependent! Java 1.4 works fine but Java 5.0 => Null Pointer Exception. It has to do with the GifImage.DummyConnection class. It pass null as the URL argument to its superclass constructor and it is that null URL which is causing the NPE. Why doesn't it happen with JDK 1.4? Not sure, but URLImageSource.getConnection will return the existing connection the first time its called and reestablish the connection the 2nd time its called. Under JDK 1.4 its appears to be called only once. To fix this I need to give the constructor the proper URL of the image but this is not available within the class. I am reluctant to change all the interfaces, which would affect all image handlers, to carry the URL as well as the InputStream just for this problem which is specific to GIF. Any one out there with some ideas here? Thanks Manuel > Jeremias Maerki
Re: external-graphics supported formats
On 09.08.2005 13:57:09 Manuel Mall wrote: > On Tue, 9 Aug 2005 06:21 pm, Jeremias Maerki wrote: > > On 09.08.2005 11:55:55 Manuel Mall wrote: > > > > PNG and TIF seem to be working although they are shown at a > > > different size than the original JPEG. > > > > Please check that the DPI/resolution settings in the different > > versions of the file are not different and if they are evaluated by > > the analyzer at all. > I'll investigate this. Thanks! > > > > BMP and GIF cause > > > exceptions. > > > > That's not so good. > > > I'll investigate this. Thanks again. > > > Is this something worthwhile to further investigate or are these > > > known issues not considered important at the moment? > > > > I consider this relatively important. There are certain problems in > > image handling ATM. Some things to keep in mind: > > - images may be highly renderer-dependant (PDF can directly embed > > JPEG and EPS, PostScript, too, Java2D cannot etc. etc.) > > - It's important to note what kind of image library you have present > > (none, JAI, JIMI). There is some overlap in what which library > > supports which image format and which gets priority in which case. > > :-) - Again, the Wiki task list contains hints that there are certain > > things to be done (look for "graphics" under "Layout of"): > > http://wiki.apache.org/xmlgraphics-fop/FOPProjectTasks > > > > I did check the WIKI for graphics items - here is my assessment - > comments more that welcome: > > a) borders on e-g and i-f-o: > There are test cases for this and they appear to work - anything > outstanding? Probably not. I've done that recently and forgot to remove that line. > b) tests for e-g and i-f-o: > More test cases have recently been added - anything important > outstanding? Yes. I stopped at the point where I had problems positioning an e-g or an i-f-o on a line. I didn't get the image to fill up the whole height of a line. Probably has to do with line-stacking-strategy. I didn't have time, yet, to investigate more closely. > c) revisit URI resolution and custom image/stream injection: > Is this really important to get 0.9 out of the door? Not for the first release, no. But it is a relatively high priority IMO. > d) Make image providers pluggable and priorities per image format, not > per provider. > Is this really important to get 0.9 out of the door? Same as c) > e) Investigate strange behaviour with certain URIs: > I did investigate this and provided a patch related to relative URLs - > anything outstanding? I have yet to look at your patch. I'm still kind of wrapped up in inlines (i.e. I found a problem). Jeremias Maerki
Re: external-graphics supported formats
On Tue, 9 Aug 2005 06:21 pm, Jeremias Maerki wrote: > On 09.08.2005 11:55:55 Manuel Mall wrote: > > PNG and TIF seem to be working although they are shown at a > > different size than the original JPEG. > > Please check that the DPI/resolution settings in the different > versions of the file are not different and if they are evaluated by > the analyzer at all. I'll investigate this. > > BMP and GIF cause > > exceptions. > > That's not so good. > I'll investigate this. > > Is this something worthwhile to further investigate or are these > > known issues not considered important at the moment? > > I consider this relatively important. There are certain problems in > image handling ATM. Some things to keep in mind: > - images may be highly renderer-dependant (PDF can directly embed > JPEG and EPS, PostScript, too, Java2D cannot etc. etc.) > - It's important to note what kind of image library you have present > (none, JAI, JIMI). There is some overlap in what which library > supports which image format and which gets priority in which case. > :-) - Again, the Wiki task list contains hints that there are certain > things to be done (look for "graphics" under "Layout of"): > http://wiki.apache.org/xmlgraphics-fop/FOPProjectTasks > I did check the WIKI for graphics items - here is my assessment - comments more that welcome: a) borders on e-g and i-f-o: There are test cases for this and they appear to work - anything outstanding? b) tests for e-g and i-f-o: More test cases have recently been added - anything important outstanding? c) revisit URI resolution and custom image/stream injection: Is this really important to get 0.9 out of the door? d) Make image providers pluggable and priorities per image format, not per provider. Is this really important to get 0.9 out of the door? e) Investigate strange behaviour with certain URIs: I did investigate this and provided a patch related to relative URLs - anything outstanding? Manuel > > Jeremias Maerki
Re: external-graphics supported formats
Jeremias Maerki wrote: BMP and GIF cause exceptions. That's not so good. Bad news indeed. Is this something worthwhile to further investigate or are these known issues not considered important at the moment? I consider this relatively important. There are certain problems in image handling ATM. Some things to keep in mind: - images may be highly renderer-dependant (PDF can directly embed JPEG and EPS, PostScript, too, Java2D cannot etc. etc.) - It's important to note what kind of image library you have present (none, JAI, JIMI). There is some overlap in what which library supports which image format and which gets priority in which case. :-) - Again, the Wiki task list contains hints that there are certain things to be done (look for "graphics" under "Layout of"): http://wiki.apache.org/xmlgraphics-fop/FOPProjectTasks I also consider this to be important. GIF must be working before we can do a release. Chris
Re: external-graphics supported formats
On 09.08.2005 11:55:55 Manuel Mall wrote: > Hi, > > I just converted the bgimg300dpi.jpg image using Photoshop into PNG, > BMP, EPS, TIF and GIF formats and tried to include those as e-g. > > PNG and TIF seem to be working although they are shown at a different > size than the original JPEG. Please check that the DPI/resolution settings in the different versions of the file are not different and if they are evaluated by the analyzer at all. > EPS shows blank. For PDF, that is to be expected. Acrobat Reader doesn't have a PostScript interpreter, and we don't, either. GhostScript should display the EPS in the PDF, though. And the EPS should show up when rendered using the PS Renderer (although that one is not yet up-to-date). Furthermore, the use of EPS is deprecated by newer PDF specs. Newer Acrobat versions might not even pass the EPS files through to the printer when printing on a PostScript printer. > BMP and GIF cause > exceptions. That's not so good. > Is this something worthwhile to further investigate or are these known > issues not considered important at the moment? I consider this relatively important. There are certain problems in image handling ATM. Some things to keep in mind: - images may be highly renderer-dependant (PDF can directly embed JPEG and EPS, PostScript, too, Java2D cannot etc. etc.) - It's important to note what kind of image library you have present (none, JAI, JIMI). There is some overlap in what which library supports which image format and which gets priority in which case. :-) - Again, the Wiki task list contains hints that there are certain things to be done (look for "graphics" under "Layout of"): http://wiki.apache.org/xmlgraphics-fop/FOPProjectTasks Jeremias Maerki
