On 30 Jun 2009, at 11:10, Peter Coppens wrote: Hi Peter
Line nrs in AbstractImageSessionContext do not match with what I see but Iam not using trunk.What I found out debugging is that the A9C3 character is escaped as %A9%C3 when the url is contructed but that in the toFile method %A9 and %C3 areinterpreted as 2 different characters.
Indeed, that already looked a bit suspicious to me, and may be the source of the issue. Seems more robust to use java.net.URLDecoder instead of re-inventing the light-bulb.
I have attached a small patch for you to try out. Would be good if you could confirm this fixes the issue on your end.
I am also confused on why you get "resolve on héxlæ.png canRead returns false"Perhaps your machine/filesystem is not using utf8 and/or saving the file didnot use utf8 or something like that
Oops, no. My bad. It becomes apparent when looking at the resolved URI why that is the case. It just goes looking in the wrong directory... :-/
Not entirely sure but this may also point to a possible cause (?)Your sample app uses "new File(href)", but as the output shows, that href is nothing more than the URI as specified in the source document. The code will only work if the image is available in the current working directory.
When I use an absolute URL as the src property, I get something like:Jun 30, 2009 11:23:51 AM org.apache.xmlgraphics.image.loader.impl.AbstractImageSessionContext newSource SEVERE: Unable to obtain stream from system identifier 'file:/ Developer/javatools/xml-fop-trunk/file:/users/andreas/documents/xml/h %C3%A9xl%C3%A6.png'
Even though the URL is absolute, the current working directory is prepended. Expected, since the File() constructor expects an abstract pathname, not a URI. It only works correctly if the file:- prefix is omitted, but then...
I run the process from FOP's base directory, so if the File constructor is called with a relative URI as its argument, it interprets that as a relative pathname. If File.toURL() is called by the StreamSource constructor, the expanded pathname and the derived URI point to a file that does not exist.
Running the process from the directory where the document and image reside, and using the attached patch, I got no more errors.
xgcommons-patch.patch
Description: Binary data
Regards, Andreas Delmelle mailto:andreas.delmelle.AT.telenet.be jabber: [email protected] skype: adlm0608 --- "Everybody I know who is right always agrees with ME."
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
