[sw-l] challenge for programmers - SSS-ID mapping onto Unicode
sw at PASSITONSERVICES.ORG
Thu Jun 23 01:21:15 UTC 2005
See comments below ...
On Jun 22, 2005, at 22:08, Steve Slevinski wrote:
> Hi Tomas,
> Rotation is needed in the IMWA because rotation doesn't always mean
> rotation. Load up SignMaker and drop a face, then press rotate.
You are tying the IMWA to a specific function in SignMaker. That does
not mean that every input editor will necessarily approach it that way.
See more comments on this below ...
> Or try the contact symbol and press rotate.
> Rotation only means mathematical rotation with handshapes and some
That is fine. It doesn't really matter because we can tell the
renderer exactly what rotation means for different types of symbols.
Perhaps you don't realize that there are a number of writing systems
that do equally complex things. If you have this vowel next to this
consonant then the form changes. Or if the consonant is in the
beginning of the word, it looks like this, but it looks different if it
is in the middle or at the end. Each writing system has it
peculiarities, and Unicode has dealt with each one of those. So we
can tell it that for handshapes and arrows, it works this way, but for
other symbols it works a different way. So, I am less concerned about
> The more we discuss this, the less value I see in Unicode. If
> sorting and special commands (Variations, Mirror, Fills, and
> Rotations) can only be done with the SSS ID numbers, what value does
> Unicode offer?
There are ways of identifying sorting order and other such concerns
with Unicode. Whether it involves a mapping database like Tomas
described or some other process, I still don't consider it to be
insurmountable. We can do it.
Frankly, Steve, I get the impression that you have come to a conclusion
about Unicode without even exploring all of the possibilities
available. You have looked at a subset of what is done with Unicode and
then summarily thrown the baby out with the bathwater. You have done
certain things a certain way with SignMaker and the IMWA. You have
done a masterful job and that is very great and very valuable for
SignWriting. I think though that there is room for open-mindedness
about the value of Unicode without shutting the door and making summary
judgments without any experimentation. That is a bit unfair of you to
be so outspoken against other possibilities of displaying and
For those of us who wish to pursue this possibility, isn't it alright
for us to work through the issues without you summarily declaring it an
impossibility? I wasn't too keen about the whole glossing aspect of
SignPuddle when you first came out with it. I was tempted to throw the
baby out with the bathwater with your program. But I decided that you
deserved a chance to try out your ideas in the real world and figure
out what worked and what didn't work. I tried my best to come behind
your program and use it and share it with others. And now some of my
concerns, you have already developed solutions to resolve. I think it
is fair for you to accord the same kind of courtesy to those of us who
would like to see SignWriting in Unicode.
> There may be a psychological factor, but if someone doesn't accept
> sign language or SignWriting to start with, using the term Unicode
> isn't going to convince them of anything.
On the contrary, Unicode does not only have a psychological factor.
There is a practical factor involved. Once SignWriting is a mainstream
writing system just like all the other of the world's writing systems
and it is included in Unicode and the renderers in the various
operating systems are aware of SignWriting, then if I am creating a
document with mixed text (sign language(s) _and_ text), then no one has
to have a special SignWriter program or a special font or a special SVG
viewer or any other special application. They simply fire up Word or
OpenOffice or whatever wordprocessor they have and view my document.
That is the ultimate value of Unicode. It is already a standard for
writing systems worldwide and I think there is value in SignWriting
taking its place among the writing systems of the world.
It does not preclude any of your work or SVG or SWML or anything else
that we are currently working on. It is simply one of the many ways in
which SignWriting can be expressed and in my opinion should be
expressed. Now, there are some logistics that need to be resolved, but
all of your doom and gloom statements do not help us answer the
questions. They only muddy the waters.
> Even once the IMWA is encoded into Unicode, none of the existing word
> processors will be able to properly use the symbols to create signs.
> Word processors use Unicode character by character in a linear
> sequence. SignWriting uses symbols in space. Of course we will not
> encode the XY coordinates in Unicode, but the symbols only become
> signs once we put the symbols in space using XY coordinates.
If rules are written for the rendering engine, yes, the existing word
processors would be able to properly use the symbols to create signs.
You seem to forget that there is a rendering engine and rules for the
rendering engine that lies between the linear stream and the display on
the screen. We would need two additional elements (which are already in
place for other sign languages): rules for rendering engines and input
method editors. The IME would be responsible for handling the input of
SW. It could look like your design for SignMaker or it could look like
SignWriter DOS or it could look like what Sandy is working on. The
user could even decide what interface he/she prefers. The rendering
engine would then be responsible for taking in all the information in
the linear stream (probably a modification of what Valerie has already
created for SignBank to handle sign spellings) and then render the
sign appropriately. In that linear stream, we can have XY coordinates
and all the information necessary to reconstruct the sign.
It is possible but it will take some research. In my opinion, it will
be a valuable asset to the cause of SignWriting. Just like I often
argue that video and SignWriting are not enemies, but friends, so also
I say that SWML/SVG/IMWA and Unicode are not enemies but friends.
Let's keep it that way.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 6590 bytes
Desc: not available
More information about the Sw-l