[PD] OSC strings and Pd symbols

[Roman Haefeli]

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
>   
>