sf::Image::saveToFile() fails when user has special characters in his username

[GuiTeK]

When a user has special characters in his username (e.g. "Sébastien", notice the "é"), and he chooses to save an image under a path which contains the username (e.g. C:\Users%USERNAME%\Desktop under Windows), sf::Image::saveToFile() fails with the error: "Failed to save image FILENAME" (file ImageLoader.cpp, line 261, SFML 2.1).

It would be good if sf::Image::saveToFile() was overloaded in order to accept an std::wstring instead of an std::string.

[LaurentGomila]

The problem is that most 3rd-party libraries used by SFML to save resources don't support Unicode filenames. So I don't know if SFML itself can work around this limitation.

[FRex]

You can only save to files named by const char * paths. This is a limitation of stb_image_writer which is used for saving images (and by extension - this is C standard library limitation, on Linux you could use UTF-8 in the const char * transparently but on Windows you need const wchar_t * and platform specific code since fopen doesn't seem to care about UTF-8 (?)).

[Ixrec]

I was able to make non-ASCII filenames work a while back simply by
converting wstring filenames to UTF-8 encoded strings before passing them
to saveToFile(). I was opening and saving both images and text files this
way. I'm not sure if it's a good idea for SFML to do anything like that,
but it definitely worked.

On 25 June 2014 16:00, Laurent Gomila notifications@github.com wrote:

The problem is that most 3rd-party libraries used by SFML to save
resources don't support Unicode filenames. So I don't know if SFML itself
can work around this limitation.

—
Reply to this email directly or view it on GitHub
#647 (comment).

[FRex]

That worked even on windows?

[Ixrec]

I did most of my development on Windows, so if it didn't work there it
wouldn't still be in my code.

On 25 June 2014 16:11, Błażej Dariusz Roszkowski notifications@github.com
wrote:

That worked even on windows?

—
Reply to this email directly or view it on GitHub
#647 (comment).

[FRex]

Maybe something else is wrong then with @GuiTeK code or source file encoding.
This is still a missing 'feature', you can load from file in memory but can't save to file in memory. API is now asymmetric like that.

[Ixrec]

If it helps, here are the relevant snippets of my code:

/* Part of the save function */
RenderTexture screencap;
// draw everything to the rendertexture except the save menu itself
screencap.display();
Image pic = screencap.getTexture().copyToImage();
if(!pic.saveToFile(wstring_to_utf8(pic_file))) {
throw(L"Failure to save screenshot to file '" + pic_file + L"' as part
of a save operation.");
}

/* Part of my utility header /
//this function was written by http://www.cplusplus.com/user/Disch/
//taken from his post
http://www.cplusplus.com/forum/general/31270/#msg169285
std::wstring utf8_to_wstring(const char str);

//this function I made myself based on Disch's function above
std::string wstring_to_utf8(std::wstring line);

I was a bit of a noob when I did this and I can see all the things that are
wrong with it now, so don't worry about educating me. It definitely worked
though. I could paste the full code for wstring_to_utf8, but that link
should give you a pretty good idea how low-level and hacky it was (I did
learn a lot about encodings though!).

On 25 June 2014 16:16, Błażej Dariusz Roszkowski notifications@github.com
wrote:

Maybe something else is wrong then with @GuiTeK
https://github.com/GuiTeK code or source file encoding.
This is still a missing 'feature', you can load from file in memory but
can't save to file in memory. API is now asymmetric like that.

—
Reply to this email directly or view it on GitHub
#647 (comment).

[LaurentGomila]

You know that SFML has UTF conversion classes, and that sf::String can also do it in an even easier way, right?

I'm surprised UTF-8 worked out of the box on Windows. The encoding assumed for filenames should be the system one, which is usually not UTF-8 on Windows.

[eXpl0it3r]

I added some tags, but the question is, can this issue be fixed? If so, how?

[LaurentGomila]

The only clean way to solve this problem is to use sf::String everywhere and then making sure the underlying libraries that use them are able to interpret them correctly. If they can't, we would have to know which 8-bit encoding is assumed for the filesystem, and convert the sf::String to this encoding before passing the filename to the loading/saving library.

[eXpl0it3r]

But if FRex's comment

You can only save to files named by const char * paths. This is a limitation of stb_image_writer which is used for saving image

holds true, how does using an sf::String help? Can non-ASCII characters be represented as a char?

[LaurentGomila]

First, we still have the option to patch stb_image_writer so that it uses the fopen equivalent that accepts wide strings. But let's hope we won't have to do that.

Of course non-ASCII characters can be represented as char. Any 8-bit encoding can fit in a char, and those are usually called "extended ASCII" -- they use the available non-ASCII range [128 - 255] to add more characters. This can be Latin-1, CP1252 or all the Windows code pages, etc. Of course it will never cover all the Unicode range, since it has at most 128 more characters than ASCII, but it will most likely do the job since it will (should?) match the OS encoding, and thus what the user is used to.

For example, french Windows use CP1252, which is an extended Latin-1, and thus contain all the european accentuated characters.

Of course on Unixes which default to UTF-8, there's no problem at all :)