Dear list,
I am working on a project with people in China and sent them a project with a main patch and a couple of subfolders for abstractions and audio files. I'm using [declare -path abstractions] so PD finds the files relative to the main patch. I tested the patch (I copied the same .zip file that I'm sending) in an older windows machine I have and it works fine, but the chinese colleagues are having some trouble. They sent me a screenshot of the console and PD can't find any of the subpatches or audio files. Do you have any experience with this? They are using Pd 0.51.2 on a Windows 10 machine with the operating system in chinese. I checked and they didn't change the folder structure.
Cheers, Maxi
On 10/22/20 3:36 PM, Maximiliano Estudies wrote:
Dear list,
I am working on a project with people in China and sent them a project with a main patch and a couple of subfolders for abstractions and audio files. I'm using [declare -path abstractions] so PD finds the files relative to the main patch. I tested the patch (I copied the same .zip file that I'm sending) in an older windows machine I have and it works fine, but the chinese colleagues are having some trouble. They sent me a screenshot of the console and PD can't find any of the subpatches or audio files.
could you also share this screenshot (at least the important parts, without disclosing confidential information)?
Do you have any experience with this? They are using Pd 0.51.2 on a Windows 10 machine with the operating system in chinese. I checked and they didn't change the folder structure.
like most people here (judging from the lack of responses to your email) i have little experience with chinese systems.
the first thing that comes to my mind when reading your problem description is a character representation issue. Pd uses UTF-8 (a Unicode variant) to represent characters. this is pretty standard in the entire world, except for Windows where UTF-16 (if they use unicode at all) is used.
i think Pd is pretty well tested for doing a proper conversion between it's UTF-8 representation and the wide-char (UTF-16) representation needed on Windows - but these tests are mostly done on "western" systems, where the characters are practically always formed by unicode-points <65536 (which is the highest number that can be represented by an (unsigned) 16bit value; UTF-16 uses 16bit (hence the name) as the base number size).
afaik (but - see above - i know little) the standard code points for chinese letters are in the range of 0x4E00..0x9FFF, so they would well fit into the 16bit constraint. but then: you never know what encoding they really use.
so:
- could you share the screenshot?
- would it be possible to find out which character encoding is used by
your colleagues? and which codepage? and...? i'm not on windows but a quick websearch revealed [1], which has at least a bit of information on how to get all these things)
- would it also be possible to get the full path to one of the failing
abstractions as *text*? (not as a screenshot).
gfmdasrf IOhannes
PS: another thing: if you are using externals that open files by themselves, they really *should* use Pd's file-opening functions if they want to open non-ASCII filenames. so if the problematic files are not opened via externals, it could well be a bug in the externals (though from your description i figure that Pd itself is having problems)
Dear IOhannes,
thank you for your answer. Here is the screenshot they sent me. https://postimg.cc/GB6z9Wb0 I'll also try to find out the character encoding and codepage they are using, the thing is, I don't talk directly to the museum technicians in charge of the setup, there is a representative there that translates all the communication and he doesn't have much experience with the subject, so I'm not sure if it will work. I asked them to put all the abstractions and files in the same folder and that worked. They also have access to a computer running MacOS for testing, and the original patch with subfolders worked there without problems.
Does the absolute path to an abstraction play a role even if using [declare -path]? and how is this different from having both patches in the same folder?
Cheers, Maxi
El mar., 27 oct. 2020 a las 9:28, IOhannes m zmoelnig (zmoelnig@iem.at) escribió:
On 10/22/20 3:36 PM, Maximiliano Estudies wrote:
Dear list,
I am working on a project with people in China and sent them a project
with
a main patch and a couple of subfolders for abstractions and audio files. I'm using [declare -path abstractions] so PD finds the files relative to the main patch. I tested the patch (I copied the same .zip file that I'm sending) in an older windows machine I have and it works fine, but the chinese
colleagues
are having some trouble. They sent me a screenshot of the console and PD can't find any of the subpatches or audio files.
could you also share this screenshot (at least the important parts, without disclosing confidential information)?
Do you have any experience with this? They are using Pd 0.51.2 on a
Windows
10 machine with the operating system in chinese. I checked and they
didn't
change the folder structure.
like most people here (judging from the lack of responses to your email) i have little experience with chinese systems.
the first thing that comes to my mind when reading your problem description is a character representation issue. Pd uses UTF-8 (a Unicode variant) to represent characters. this is pretty standard in the entire world, except for Windows where UTF-16 (if they use unicode at all) is used.
i think Pd is pretty well tested for doing a proper conversion between it's UTF-8 representation and the wide-char (UTF-16) representation needed on Windows - but these tests are mostly done on "western" systems, where the characters are practically always formed by unicode-points <65536 (which is the highest number that can be represented by an (unsigned) 16bit value; UTF-16 uses 16bit (hence the name) as the base number size).
afaik (but - see above - i know little) the standard code points for chinese letters are in the range of 0x4E00..0x9FFF, so they would well fit into the 16bit constraint. but then: you never know what encoding they really use.
so:
- could you share the screenshot?
- would it be possible to find out which character encoding is used by
your colleagues? and which codepage? and...? i'm not on windows but a quick websearch revealed [1], which has at least a bit of information on how to get all these things)
- would it also be possible to get the full path to one of the failing
abstractions as *text*? (not as a screenshot).
gfmdasrf IOhannes
PS: another thing: if you are using externals that open files by themselves, they really *should* use Pd's file-opening functions if they want to open non-ASCII filenames. so if the problematic files are not opened via externals, it could well be a bug in the externals (though from your description i figure that Pd itself is having problems)
[1] https://serverfault.com/questions/80635/
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
IOhannes m zmoelnig -
Maximiliano Estudies