Re: Writing a proposal for an unusual script: SignWriting

From: Stephen Slevinski (
Date: Mon Jun 14 2010 - 11:21:38 CDT

  • Next message: Leonardo Boiko: "Re: Most commonly used characters not in BMP"

    Greetings Asmus Freytag,

    Plain text SignWriting should be able to write actual sign language,
    such as "hello world."

    This is a combination of 2 signs and 1 punctuation. The first sign has
    2 symbols. The second sign has 4 symbols. Punctuation is always used
    by itself.

    You can see this online being processed in JavaScript:

    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.

    > From the way you describe the requirements (faithfully representing
    > the minutest details of the authors choice of placements, etc.) and
    > your claim that the plain text level should not / does not encode
    > semantic contents, I get the impression that you have not fully
    > thought through what information should be represented at what level
    > of the text architecture.
    I prefer the term phonemic rather than semantic. Most symbols are
    phonemic. A minute few of the symbols are featural. It requires
    several featural symbols to build a phonemic representation, such as a
    new handshapes that a particular author feels is absolutely needed.

    While not a linguist, I would say that the semantic meaning of
    SignWriting is contained in the spatial layout of the symbols. We do no
    encode the semantic meaning directly, but the semantics can be perceived
    when a sign is considered as a whole. Some of the semantics are not
    even included in the writing, but left for the reader to infer. An
    example would be a starting handshape that is not written but can be

    > Concretely: do you see the need for, existence of a SignWritingML?
    I see no advantage to requiring XML for plain text. Years ago, I was
    using a comma delimited format for the data. I took the advice of
    others and moved to an XML format: specifically SWML-S. It was a
    misstep. Same data, but more complex processing. Now, with the
    character encoding, I can represent plain text SignWriting as character
    data. Easy to parse, search, sort, and display. There is no advantage
    to using XML; however, I have created an equivalent XML (called BSWML)
    with roundtrip mapping between character data and XML. I personally
    will not be using XML for plain text, but I thought others might
    appreciate the possibility.

    > Do you think, existing HTML could correctly render SignWriting if that
    > was presented as part of the plain text data (under your proposal)?
    I have both client side and server side processing of SignWriting. The
    server side uses PHP and passes completed sign or column images to the
    client. The client side processing uses JavaScript, CSS, and HTML to
    correctly represent the SignWriting. The HTML specifically uses DIV
    tags with relative positioning. Each symbol is positioned with it's own

    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.

    > What happens when a user agent selects a different font, because the
    > one the author used is unavailable on the system used by the reader?
    For SignWriting the font designer has strict rules of size and shape.
    The font designer can modify the symbol glyphs only under these
    restrictions. With the number of symbols involved, no font designer
    would break these rules and waste their time designing a font that would
    not work with the writing system.

    The major choice will be between a raster font and an SVG font. The
    raster font is completed. The SVG font is a work in progress.
    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.

    Here's a few simplified examples.

    First the sign for dinner in American Sign Language.

    Next is the sign for German in German Sign Langauge:

    Each sign has two symbols: one hand and one head. The fill color of
    each hand symbol covers part of the head line. The symbols represent
    the phonemic information, while the semantics are perceived by the
    symbol position.

    In SignWriting we write the symbols in space, so all we encode is the
    positions of the symbols. In HamNoSys, you would encode dinner as round
    index hand on chin, and German as closed index hand on forehead.

    The difference effects how the writers think while they write. For sign
    language, everything is visual. The language center of their brain is
    wired to their eyes. They look at the symbols and see phonemic
    information. They construct a sign by placing symbols on a canvas.
    They perceive the semantic information not only between any two symbols,
    but the semantic information contained by all of the symbols taken
    together. They look for shape and pattern. This greatly affects how
    someone reads.

    We've had large discussions about spelling on the SignWriting list.
    Someone will write a sign and others will comment. People will try to
    rewrite the sign to be easier to read. It's amazing what a difference a
    small adjustment in symbol placement can make. A sign that was
    difficult to read automatically becomes easy and clear. The improvement
    in the sign was only possible because of an excellent writer who
    understood the sign as a whole and was able to build a cohesive
    representation. SignWriting is part artistry. Is simple to start, but
    the best writers have an eye for symbol choice and symbol position.

    Maybe that's why I'm such a proponent for exact symbol placement: it's
    the only way to achieve the best writing. I'm sure a system could be
    devised that produced average or adequate writing, but it will never be
    able to produce the quality of writing that an experienced writer can

    My focus is to make the best encoding for the reader and the writer.
    Let the designers and programmers handle the extra complexity.

    > In some of your answers you've given a few hints, but for someone like
    > me who has no firsthand experience of signing and difficulties
    > visualizing sign writing, you probable will want to be way more
    > explicit and concrete in your description and examples, so that it
    > becomes possible to evaluate whether your choices in the encoding
    > model are the correct ones, or possibly the only ones, or whether, on
    > the contrary, the represent an unnecessary departure from the way
    > Unicode deals with non-linear notations.
    I appreciate your consideration and thought. I will put more detail in
    the official proposal later this year. The current documents are to
    define the open standards for data sharing between projects.

    Perhaps you'd like to read a short piece by Adam Frost titled "Why
    SignWriting?" in English and ASL.


    This archive was generated by hypermail 2.1.5 : Mon Jun 14 2010 - 11:23:14 CDT