From: Rick McGowan (firstname.lastname@example.org)
Date: Mon Jun 14 2010 - 16:00:07 CDT
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
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:
The set of entities listed in Steven's report is divided into several
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.)
This archive was generated by hypermail 2.1.5 : Mon Jun 14 2010 - 16:02:44 CDT