Yup, this is definitely OK according to the v2 migration docs:
loadFont()andloadImage()caches the font/image by its path, so this operation can be efficiently called indraw()every frame.
^ This looks a bit like I’m throwing the whole doc at you, but it’s actually a direct link to the section I quoted, just to prove I’m not talking out of my ass. 
Great! That’s what I thought, but I just wanted to be sure!
Sorry what’s the problem? Could you ask them to report the bug to us? The version in beta will be the library version in the next upgrade though
This is related to the utf16 insanity on windows right? I thought the rack apis took care of that but maybe not.
I still think @cosinekitty idea is a good idea. If it were me, I would try it. Even if the bug is in rack, that might tell you.
Done! The user’s name is Aurélien. I asked him to open a ticket with you. Thanks!
Ok, that’ll be my next step in troubleshooting. 
So here’s the thing I don’t understand
APIs like rack::asset::plugin have type std::string. The documentation says on windows some items which require a UTF16 string require you to call rack::string::UTF8ToUTF16 which returns a std::wstring and the rack code has, in a few places, a call to that and then a call to .c_str() (notably not .wc_str()) before a load. For instance here’s some code on how to set up an archive from src/system.cpp
// Open file
#if defined ARCH_WIN
r = archive_write_open_filename_w(a, string::UTF8toUTF16(archivePath).c_str());
#else
r = archive_write_open_filename(a, archivePath.c_str());
#endif
but Svg::load has signature const std::string & and all through the rack code the calls to Svg::load use the output of rack::asset::system directly. So I am presuming that somehow nvgSvgParse has been patched like fopen has
Is there a definitive set of APIs which require you to call UTF8toUFT16? My understanding was it was
char * requires the conversion on windows, as abovestd::string does not (and cannot since UTF16 returns a std::wstring)That makes me think that, in the Surge XT case, our call to json_load_file probably needs an ifdef and protection but our call to loadSvg does not. Explicitly this code:
setSvg(
rack::Svg::load(rack::asset::plugin(pluginInstance, compDir + "/" + knobPointerAsset)));
bg->setSvg(rack::Svg::load(
rack::asset::plugin(pluginInstance, compDir + "/" + knobBackgroundAsset)));
should work on all OSes even ifs someone on windows has their directory as "c:\Magical 
" but the json_load_file needs protection
Not that I have a bug report other than a mention here in this thread though! And I won’t have a windows box available until at least the end of the weekend.
Oh but to the original question or rack::system::exists its implementation is
bool exists(const std::string& path) {
try {
return fs::exists(fs::u8path(path));
}
catch (fs::filesystem_error& e) {
return false;
}
}
so it clearly expects a UTF8 path inbound (and uses ghc filesystem, which is a sub in for std::filesystem that we also have used in surge). So as long as you aren’t doing any math on your string you should be fine since it’s all UTF-8 up to that api point as far as I can see. Maybe?
again like I said I don’t have a bootable windows box to test on right now.
Assuming this name is spelled correctly (which seems likely), and assuming you or the user didn’t mangle the log output in a text editor, and assuming that the users´ home directory is actually C:\Users\Aurélien\ on disk, then comparing with the original log output you presented in the top post:
[0.003 info adapters/standalone.cpp:140 main] User directory: C:/Users/Aurélien/Passeport Elise/Rack2
[0.003 info src/settings.cpp:488 load] Loading settings C:/Users/Aurélien/Passeport Elise/Rack2/settings.json
it seems clear that something in Rack is choking on that special char in the name. >> é << got mangled into >> é <<. It could be something innocent in the log printout function of course, but given the issue at hand, probably not, and likely a sign that Rack is probably still not correct throughout with respect to character encoding and handling.
Line 140 of adapters/standalone.cpp in the Rack code is:
INFO("User directory: %s", asset::userDir.c_str());
As others have pointed out above, crossplatform string and filename handling, especially because of Windows, is a bleeping nightmare.
And even though it would work, if not for bugs, I always say that no programmer would create a user name with non ascii characters. It’s just asking to be bitten by bugs.
It was a lot of work to get SFZPlayer to work on all platforms with Unicode file paths.
True, and I adhere to the same from bitter experience. But for normal users they often don’t have a choice, and/or don’t know the ramifications when they innocently type in their actual name in their language. It should be reasonable to assume that “things just work”, except they don’t of course, and that’s just another reason that people (rightly) distrust IT. Heck, in my bitter old days as a programmer now, I have come to largely shy away from “smart things”, and generally prefer low tech whenever possible. Sigh…
Not related to anything I’ve done with rack, but I did once have VSCode decompose some unicode into precursor characters so that some literal unicode strings HAD to be expressed as unicode code numbers.
Quick update – A reinstall of Windows 10 solved the user’s issues, but I didn’t glean much new information from his message. I also haven’t run tests (as suggested by Squinky and Baconpaul) myself yet and hope to do that soon.
After a complete reinstallation of Windows 10, VCV works like a charm, and your plugins too
I strongly suspect the default “Document” folder, because I met similar problems with a VST, which couldn’t display the built-in presets stored in that “Document” folder.
Well good thing is I found one spot in surge where we might have an issue which I’ve fixed. It’s just that user skin preferences may not be saved with unicode user names, nothing fatal but definitely that review of my code made me fix one spot.
The was a time a while back where a user was getting some very odd behaviour with the display of MindMeld modules.
He reported it to us on a Sunday morning and Marc and I spent a good part of our Sunday (around 4 or 5 hours) investigating…
It eventually transpired that he had a Cyrillic username or some such and right at the end he told us none of his other Rack plugins were displaying properly either… so it was never a MindMeld issue in the first place. And he had already reported the issue to VCV the day before in regards to Fundamental modules… it was a bug in Rack.
Grrrrr.
Good news. Maybe he chose a different username this time, you should ask him.
Yeah, users can be pretty “interesting” with their problem reports 
I have woved never to work in support.
This will surprise no-one, I’m sure. Back in the late 80’s I used to talk to customers on the phone. Some were super nice, like Peter Asher and Kraftwerk. Many were not.
Once I told a customer I would refund his full purchase price of our software ($500 way back then!) if he promised to never use it again or call again.
Eventually the company developed a policy that if you put a customer on the phone with me and something bad happened, it was not my fault, it was the fault of whoever forwarded the call to me.
UTF-8 printed as ISO-LATIN?
Could be. However filenames on Windows would rarely be UTF-8 but rather some “Latin” variant in this case, so my guess would be the other way around - Latin printed as UTF-8 by Rack, which I think tries to be UTF-8 throughout.
Not sure how I missed this one until now - Love it! I needed a good laugh 