Re: Writing a proposal for an unusual script: SignWriting

From: Mark E. Shoulson (
Date: Mon Jun 14 2010 - 15:18:51 CDT

  • Next message: "Re: Latin Script"

    On 06/14/2010 02:15 PM, Asmus Freytag wrote:
    > On 6/14/2010 9:21 AM, Stephen Slevinski wrote:
    >> Greetings Asmus Freytag,
    >> Plain text SignWriting should be able to write actual sign language,
    >> such as "hello world."
    > You could equally well insist that it should be possible to express the
    > opening bar of "twinkle, twinkle little star" in plain text, or write
    > the "square root of the inverse of a plus b" in plain text.
    > In both cases, you would be disappointed and find that a markup language
    > is required, such as MathML, although specifically for math, it is
    > possible to device an extremely light weight markup language that comes
    > close to plain text.

    It is all too tempting and too easy for discussions of "Why X Should be
    Encoded in Unicode" to devolve into "Why X is So Incredibly Useful." In
    this case, I don't think that's the point. Unlike some other proposals,
    I think it is clear (to me, anyway) that SignWriting has a fairly solid
    user-base and also an important use (transcribing signed languages,
    which don't really have too many other ways of being transcribed.
    Things like HamNoSys are also not encoded yet). 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?" If it does not (and cannot be made to
    do so), then no matter how useful SignWriting is, it may simply not be
    encodable. It's not because it doesn't deserve to be, and yes, that
    would really be a bummer because it would relegate signed languages to
    second-class, but Unicode has its limitations, and SignWriting may well
    be beyond its capabilities.

    (That said, I find myself thinking that it *should* be possible to align
    Unicode and SignWriting. But I recognize that it might not be.)

    > This does not work for me.
    >> I dislike the idea of requiring a higher level protocol in order to
    >> encode plain text SignWriting. I have used CSS to change the color and
    >> size of SignWriting. I chose not to include color or size in the plain
    >> text representation of SignWriting because color and size do belong in
    >> the higher level protocol.

    Color is explicitly out of scope for Unicode. Glyphs are monocolor.

    > Not all streams of concrete small integers are ispso facto plain text,
    > even though you can map these integers to the private use space.

    I guess you would need to establish a distinct and independent meaning
    for each code-point, which would have to be something more specific than
    "...and then you give the x-coordinate."

    >> For the future, I am considering a browser plugin that will detect and
    >> render SignWriting character data. A regular expression could scrape
    >> the appropriate PUA characters. Another regular expression could
    >> validate that the characters represent valid structures. Then the
    >> SignWriting display could be built using individual symbols, completed
    >> signs, or entire columns.
    > In other words, a layout engine.

    Is there such a thing as SignWriting without a layout engine? I guess
    the same question could be asked about Musical notation (though I think
    it probably could have been coded as plain text. See also for a very powerful musical notation using only
    ascii, but decidedly *not* plain-text in nature).

    > If SignWriting cannot be successfully used except with 2 fonts, then I
    > see little need for standardizing the code. What you describe is a
    > private use scheme, even though the private group may have many members.

    I'm not sure I agree with this. Just because only two fonts are out
    there so far, and the character-shapes perhaps allow a little less
    flexibility than some, doesn't mean that other fonts aren't possible.
    Nor is the multiplicity of fonts a requirement for encoding.

    >> SignWriting has the unusual requirement of a 2 color font. One font
    >> color for the line of the symbols and another for the fill. The fill
    >> is needed when symbols overlap.
    > Hmm.

    AFAIK, Unicode can't do color. I remember someone mentioning that once.
      But someone who knows the exact rules can explain better.

    I think it will help when your proposal is ready for review so people
    will understand just what it is you are suggesting and can judge how
    much (if at all) it conflicts with Unicode's capabilities.


    This archive was generated by hypermail 2.1.5 : Mon Jun 14 2010 - 15:22:06 CDT