So I just committed a new [unpackOSC] to svn. I don't really have a sure way of generating UTF-8 in Pd so someone with a non-US keyboard will have to test it. I can do things like the accented e and mu but serious symbols end up as something like /u123 if I try to paste them into Pd.
Martin
On 2012-03-20 04:58, Roman Haefeli wrote:
Hey Martin
Do you have an opinion on this? Would it do any harm if [packOSC] and [unpackOSC] would allow UTF-8 in strings?
Roman
On Tue, 2012-03-13 at 11:08 +0100, Roman Haefeli wrote:
Hi all
Nowadays, Pd supports UTF-8 and it's possible to type non-ASCII characters into a symbol box (or a message box, if you like). This is generally good thing. When working with [packOSC], every symbolic (non-number) element is treated automagically as a OSC string (unless you create type-forced OSC messages). This generally is also a good thing. The OSC specification states that OSC strings must only contain ASCII characters (which I find a real PITA). As a patch writer, however, I have no measure to make sure, that only pure ASCII symbols are sent to [packOSC].
Currently, the situation is that [packOSC] happily creates invalid (according to the specification) OSC strings, but only [unpackOSC] complains about it when receiving such a string. The error in the console:
unpackOSC: PrintTypeTaggedArgs: Type tag said this arg is a string but it's not!
I don't know what the best solution is to deal with that problem. Strictly sticking to the specification, [packOSC] shouldn't package Pd symbols containing non-ASCII chars into OSC strings in the first place or at least it should chop them off. Another way to deal with it would be to make [packOSC] and [unpackOSC] both support UTF-8 strings instead of ASCII-only strings. In other words, those classes would support an 'extended' OSC string type, which is fully compatible with the 'strict' OSC string type. This also would remove any constraints put on the kind of Pd symbols that can be used as OSC strings. Some (many/most?) other OSC implemenations are _not_ strict in that they do not check if the OSC strings only contain ASCII strings. I checked pyliblo and pyOSC and both allow to transmit deutsche Umlaute in strings. I don't know if there are also strict implementations.
The current behaviour of [packOSC] and [unpackOSC] is IMHO the least favorable, in that it still allows to create 'invalid' OSC strings (possibly causing troubles with strict non-Pd receivers), but complains about them on reception.
Any thoughts on this are welcome.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list