From: Stephen Slevinski (slevinski@gmail.com)
Date: Mon Jun 14 2010 - 11:21:38 CDT
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:
http://signbank.org/swis/bswref.html?bsw=0fb14c38e3924a54bd27138c3984bb4cf0fb18738c39c4c04c618738c3934b94b020538c3924d14b32ef38c3924c949c38838c392#v
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
assumed.
>
> 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
DIV.
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.
http://signbank.org/swis/glyphogram.php?bsw=0fb2ff38c3924f54f510138c392500500
Next is the sign for German in German Sign Langauge:
http://signbank.org/swis/glyphogram.php?bsw=0fb2ff38c3924f550910038d3925014f5
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
produce.
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.
http://www.signwriting.org/archive/docs6/sw0526-US-Why-SignWriting-Frost.pdf
Regards,
-Steve
This archive was generated by hypermail 2.1.5 : Mon Jun 14 2010 - 11:23:14 CDT