Re: Writing a proposal for an unusual script: SignWriting

From: Rick McGowan (rick@unicode.org)
Date: Mon Jun 14 2010 - 16:00:07 CDT

  • Next message: André Szabolcs Szelp: "Re: Writing a proposal for an unusual script: SignWriting"

    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



    This archive was generated by hypermail 2.1.5 : Mon Jun 14 2010 - 16:02:44 CDT