Laurent Gomila

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.

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...

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...

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...

SFML could call the memory buffer function and save it to a file itself. Less efficient, but still another option.

I was more worried about the allocation of a big continuous chunk of memory, in case the user saves huge images in an uncompressed format :)

Yes, it is still (more or less actively) developed, and we can send patches, they are usually always applied quickly if they are relevant.

> Why would anyone feed a UTF-8 string to a function expecting an ANSI string to begin with? There's no constraint on the argument's encoding. `std::string` can contain any 8-bits...

Yes of course, that's part of the plan.

Please use the forum to discuss such issues next time. This tracker is for confirmed features and bugs. And please provide a more complete description of your problem and environment...