OK, I wasn't going to weigh in here, but...

On 6/14/2010 1:18 PM, Mark E. Shoulson wrote:
Here, the question is more a matter of "given that SignWriting is nifty, does it qualify as plain text?" Or even "Does the way SignWriting does its thing map well to the way Unicode does things?"

After looking at this discussion for a while, and taking a look at what Steven Slevinski proposes, I think it matches Unicode about as well as math or music notation, or even Egyptian hieroglyphs. I.e., yes, the set of primitives seems encodable, and any English-language (or other language) pedagogical discussion of SignWriting will want *at least* the basic symbols. But... the whole system is not plain text, any more than music notation or math expressions. And even if UTC were to miraculously encode it all, with suitable semantics and lots of rules and give away a parser: nobody would implement it in standard software for the mass market, any more than they implement MdC for typesetting Egyptian Hieroglyphs.

Having said that, in theory I see no real reason (other than perhaps a bunch of intellectual property issues) that the basic symbols of SignWriting could not be encoded, given a suitable proposal, suitable stability, and assuming there is a sizable community of users.

I suggest that Steven take a look at Murray Sargent's UTN:
http://www.unicode.org/notes/tn28/

The set of entities listed in Steven's report is divided into several sections:
Structural Markers, BaseSymbols, Modifiers, Number Characters

Of those, it seems fairly obvious that the 652 "base symbols" are just symbols, which can be combined in various ways. The Structural markers could be encoded as control characters, or, in fact, as visual symbols for the thing they do, e.g.: "symbol for left lane signbox marker", much like we have encoded the pictures for control symbols. The modifiers could likewise be encoded as "signwriting fill modier X" and so forth. (In fact, the proposal shows visual representations of the rotation symbols, etc, so presumably they already exist.)

*Parsing* a stream of this stuff into something that's legible and/or beautiful is beyond the scope of the standard, and I'm fairly sure the committee wouldn't even entertain such a thing any more than they entertained specifying the layout of western music notation.

But once you've got all of those symbols encoded, you could use a light-weight protocol similar to what Murray has done for embedding Math expressions in plain text. Software that recognizes the protocol can do fancy things to the contents of the "sign zone". Off-the-shelf software that doesn't understand the protocol would do no worse than an ordinary word processor can now do with Egyptian Hieroglyphs or music symbols: blast out a line of symbols in-line.

In looking at the actual proposal, I'm not sure why sign language users are only allowed to count from -299 to 300, but presumably there's a logical explanation for that.

(This is all my personal opinion of course and does not reflect an official opinion of the consortium or the UTC.)

    Rick


Reply via email to