IMWA: Handshape Construction and Sequencing Rules

[Stuart Thiessen]

Actuallly, I think Unicode and SWML can go hand in hand.  SWML could
include how the symbols are put together. Unicode could be an easier
(and less memory intensive) way to story the glyphs themselves.  A font
generally takes less room than all the pictures and it takes care of the
sizing issues that we might have with pictures.

This needs to be studied further, but in discussions that I have had
with a Unicode expert, he said that the number of characters is not an
issue.  We can actually create a Unicode standard for SW where some
things are understood in context.  For example, Chinese in Unicode has
hidden characters which define the composition of the symbols.  If I
have a chinese character composed of 2 radicals side by side, then I can
select the hidden character that means PUT THEM SIDE BY SIDE and then
pick the two radicals and the renderer will read the three characters
and pick the glyph that best fits that. They have other hidden symbols
which help with composition issues.

We could do similar things with SignWriting.  We could have hidden
symbols that reflect shading or rotation or positioning or many other
issues and then the renderer can simply look at the string of Unicode
and select the appropriate glyph.  It is very possible. If we have
Unicode and a standard renderer for SignWriting, it would streamline the
production of SW programs immensely, rather than each program having to
develop its own methods of composing characters on the screen.

As you may or may not know, a Unicode font can have many glyphs (images
of the character) for each Unicode character. So we could have one
character for each rotation, shading, etc. or one character for each
handshape and let the renderer select the appropriate glyph for that
handshape based on the information we give to the renderer or based on
the context.

Unicode has its levels of complexity including all the approval
processes. I know we can avoid all that by just doing graphics and SWML,
but I think that will shortchange ourselves.  With SignWriting in
Unicode and the use of SWML and a common renderer and other tools we can
develop, I think this will all create an environment to convince the
hearing to allow our languages to enter the computing mainstream. It
will show that our languages can fit their existing technologies so they
have nothing to lose by adopting our rendering or conventions for
writing in our languages.

If we do graphics and SWML only, I think that we will remain in the
fringe of computing and have a difficult time convincing hearing to
incorporate our languages into their technologies.

I know the Unicode numbering could be an issue.  But we can cross that
bridge after the feedback process on the IMWA. Maybe when the dust
settles on that, we will be able to see a way to number things in
Unicode that will make sense with the numbering system of IMWA.

Does this make sense?

Thanks,

Stuart


Steven Aerts wrote:
>>I agree. But we should think for the future. Every symbol of
>>SignWriting will have a representation in Unicode. And Unicode
>>characters just are numbers. So, what I am trying to tell you? Even if
>>you use names ultimately you will have to work with numbers again.
>
> We don't think unicode is a good standard to write SignWriting.
>
> The main (and only?) reason to use unicode is that you can make a font for it.
> The difference between fonts and SignWriting is that SignWriting can rotate
> and mirror it's symbols and fonts - which are purely character based - can't.
> So the fonts will have to contain a representation for all possible
> SignWriting symbol mirrors and rotations, which will make the font too big to
> handle for a normal computer.  We never expect that you can open a unicode
> SignWriting text in your browser by only downloading the SW-font.
> If we can't use SW-unicode anywhere else expect in our own programs why use
> unicode if there is a better alternative: SWML?  That format is extensible in
> nature, has more (programming)-tools available, is more human-readable and is
> most likely smaller if compressed.
>