Re: URIResolver in combination with filenames with unicode characters fails - Problem in AbstractImageSessionContext#toFile?

On 30 Jun 2009, at 11:10, Peter Coppens wrote:

Hi Peter

> Line nrs  in AbstractImageSessionContext do not match with what I  
> see but I
> am 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  
> are
> interpreted 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 did
> not 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.





Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandreas@...
skype: adlm0608

---
"Everybody I know who is right always agrees with ME."




---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...