Can't open drawings located in folders with non-ASCII chars
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
Menu
▾
▴
#188 Can't open drawings located in folders with non-ASCII chars
See https://sourceforge.net/mailarchive/forum.php?thread_name=20120112173347.GD15958%40sonic.net&forum_name=tuxpaint-users for background.
Some thouths:
According to the user, Tuxpaint can write files at those paths.
Tuxpaint can read the file currentid.txt which most likely is located at a similar path.
SDL_Image can't open the file located at the path described by currenid.txt
This makes me think that either we have a problem encoding/decoding currentid.txt or SDL_Image has a problem with some paths,
If it is SDL_Image, a workaround I am seeing right now is to to open the file via RWops as we do for kpx images.
Another user has reported the same issue, with a username with an accented-E, on Windows 7.
Notified to the libsdl bugzilla:
http://bugzilla.libsdl.org/show_bug.cgi?id=1485
A possible workaround not specific to w32
The attached file RWopsdiff.diff fixes this problem, is mainly a copy of load_kpx() with small modifications like passing
"rb" to fopen as per w32 needs, note that the fopen call in the original load_kpx is too changed in this way.
The patch tryes to load the file first with IMG_Load, then if it fails goes with RWops, it does the same in linux and windows, linux doesn't need it, but I think the code is more clear like this rather than filling with #ifdef(s), of course it is just a fix, the real solution will be at the SDL level
Just in case somebody looks around, the patch was added to the cvs in march https://sourceforge.net/p/tuxpaint/mailman/message/30736313/