[PD] Windows in Chinese, problem with paths

[Maximiliano Estudies]

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 at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>


-- 
Maximiliano Estudies
*VDT Referat Beschallung*
+49 176 36784771
omslo.com
maxiestudies.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20201027/973a3f00/attachment.html>