On March 17, 2015 09:54:14 PM Robert Jonsson wrote: > 2015-03-15 18:06 GMT+01:00 Robert Jonsson <[email protected]>: > > 2015-03-15 16:57 GMT+01:00 Andrew Deryabin <[email protected]>: > >> Hi Robert, > >> > >> Just made tests with new fuid synth patches: > >> > >> I have LANG set to ru_RU.UTF-8 > >> > >> 1. Loading sf2 banks from paths formed from english characters works > >> fine. > >> 2. But when there is international characters found in the paths nothing > >> happens at all, and moreover after that 1 case stops working too. > >> > >> How to test: > >> > >> Create folder with unicode name: > >> > >> Банки SF2 > >> > >> Then copy some soundfonts here, set LANG to ru_RU.UTF-8, load MusE and > >> try to > >> open these sound fonts from that path. > > > > Alright, no time (or energy for that matter ;) to test this now but I will > > test and compare! > > This is so wierd. I created a folder Банки SF2 and followed the data in the > debugger. Mess synths pass data to the synth as a sysex datastream, so the > string had to be serialized, transferred and deserialized again. Turns out > I had been using toLatin1 here for whatever reason.. it had worked for my > previous paths. > For good reason it did not work here, instead I tried changing to toUtf8 > and QString::fromUtf8 and according to the debugger in Qtcreator the string > that turns up on the synth side contains the right string. But > QFile::exists(string) does not recognize that this path points ot a valid > file. Maybe the debugger is fooling me?! So as a test I bypassed this > transfer and kept the original path in a global QString, now the > QFile::exists(string) works, later on the toLocal8Bit also works and > fluidsynth loads the soundfont! > > Basically I hate encodings ;-P It seems it always a matter of trying all > the combinations..
Some of this may be my (English) fault, desiring just pure 'Western' text for printf checkpoints and so on - /somewhat/ propagating Latin1 usage. Using an example of a plugin with foreign language characters in its name, there are two pieces of text to keep handy: 1) We need to keep the original text in its original language so that when the name is stored, for example in the song file, it is not mangled by local translations or neutered by 8-bit conversions. 2) We need a localized readout of the name, if the user desires. Staring at such a plugin name would make me think "can I get a rough translation?" We may be *doomed* here, because char strings and Latin1 strings are used extensively in MusE. Our XML module (xml.cpp) is not internationalized - it writes char strings ! I direct your attention to Werner's replacement (from muse_evolution) in: al/xml,cpp I looked at the situation. It obviously would require /extensive/ modifications to our code in order to support Werner's XML module. But, there it is. And then there's the rest of MusE to deal with... The work I did in this area concerned international numerals - floats etc. I tested the code and it worked and fixed the reported issues. But I don't recall if I tested storing international text - letters etc. I'm thinking now that MusE can't possibly be doing it correct - if at all. I mean, I /have/ tested opening MusE under a different language setting, and I think we all know that seems to work fairly well. Robert and Andrew, what can you report about experiences with MusE, particularly saving and loading international (non-Latin1) text such as a plugin or the example given by Andrew? Tim. > Maybe I'll try transferring the data as 16bit unicode later.. that _must_ > work, it just seems very awkward. > > On another note, I didn't set LANG, we'll see if it matters ;) > > /Robert ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
