loader.loadModel and unicode

1 year ago, I already asked about this and the conclusion was to not use unicode character. It was ok then. But now, unfortunately, it’s not good anymore :confused:

When installing itself (on windows), my application put resources in the “AppData” folder. In these resources, there are some egg. The application load them and everything is working with a normal user (ie a user with ascii characters).
But if the user’s session name is, for example Stéphan, I can’t load them anymore. The loader can’t find the folder.
On top of that, this problem is Windows only and my application is, of course, windows only.

So, is there a way to make it works ?

Thanks in advance.

I think Panda doesn’t support unicode characters in paths and filenames… I also encounter this often.

Hmm, Windows always provides an 8.3 version of every filename. It’s an alternate name to the same file, that fits within the old MS-DOS convention of 8 ASCII letters and 3 extension letters. You could find out the 8.3 version of Stéphan’s folder name, and use that name instead.

But, yeah, this no-international-filename limitation in Panda is a problem. It ought to be easy to fix, but we have to be careful not to break old Win98 installations or whatnot that don’t even have the system functions to load international filenames.


Thanks David, it’s working with DOS 8.3 filename. :slight_smile:

For the code fix, I was more thinking at something simple, a parameter given to the loader, like loader.loadModel(path, unicode=True). It’ll not completely solve the problem but at least, the developer’ll be able to use unicode for the loader (at his own risk).
But maybe I’m missing something and it’s more complex than this and impact a lot of other stuff. :question:

It has to go to the low-level file opening commands deep in C++. There are two flavors of file commands in Windows: the original functions, which accept only ASCII filenames, and the new extension functions, which accept international filenames.

We’d have to make the low-level operations call the extension functions, but only if those extension functions actually exist on your current version of Windows. This couldn’t be easily controlled via a parameter at the Python level. But it wouldn’t really be hard to implement in C++, it’s just a matter of doing it, and taking a bit of care to do it properly.


Hmm, how about letting Panda automatically translate it into a 8.3 DOS path?

Well, that doesn’t solve anything; the translation functions only exist on certain versions of Windows too. But really, it’s not a hard problem to solve properly; I just haven’t had a chance to do it lately.