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