XMLmind XMLEditor is using custom URI resolver for FOPFactory, for all resolved URIs it is returning SAXSource rather than StreamSource. Before 1.3 and latest FOP changes, images were loaded properly, but with latest trunk of FOP I started getting: [FOP Error] No ImagePreloader for ... and then Cannot open image (because URI was cached as wrong). After hours of digging I found out that URI resolver of XMLmind is returning always SAXSource, while src/java/org/apache/xmlgraphics/image/loader/impl/AbstractImageSessionContext.java @ newSource expects StreamSource. Also image loaders work only with ImageSource, that was created only from StreamSource, with generic Source they fail. I'm attaching patch for AbstractImageSessionContext.java that checks also for SAXSource and allows using its inputSource's byte stream. This makes XMLmind FOP addon again usable with latest FOP trunk.
Created attachment 21575 [details] Patch that detects if source is SAXSource and uses its stream.
Adam, just to verify: Does xmleditor ALWAYS resolve to a SAXSource? I can understand this on xml-formatted images (such as SVG and MathML), but also for PNG, JPEG, etc.? Because if that is the case then the real question is if this should be changed in xmleditor rather than xmlgraphics: a SAXSource for JPEG images makes no sense, where as support for SVG / MathML could be greatly simplified if the SAX source is used directly. Max
Yes XMLMind is ALWAYS resolving to SAXSource, this is done because of some good reason stated in the source code :) I've forwarded this bug report to them. However I can understand this some regression in here anyhow, because with FOP 0.94 and XMLGraphics 1.2 it was working fine even with this SAXSource, but now it doesn't. So IMHO now matter how the underlaying code is written XMLGraphics shouldn't break with new release something that was working OK. (Also I think sthing is wrong with Java StreamSource & SAXSource inheritance, I'm not regular Java programmer though)
Thanks for the patch, Adam. I have taken a slightly different approach than you've taken in your patch to also properly handle Readers in SAXSources, for example. I extended the helper methods in ImageUtil so they cover SAXSource, too. Making use of that in AbstractImageSessionContext even helped simplify the code. I've also added test cases for all sorts of scenarios (StreamSource, SAXSource, DOMSource) so we're sure that the image plug-ins can deal with whatever Source subclass they want. Change in SVN: http://svn.apache.org/viewvc?rev=630423&view=rev