IMWA: Handshape Construction and Sequencing Rules

[Steven Aerts]

> 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.
As far as we know Unicode is not a font format where you can put glyphs in.  
Unicode is a text format where you can write text in.  The benefit of Unicode 
against for example ASCII is it can hold (infinitely) more different symbols 
than ASCII.  
The problem with SignWriting fonts in general is that fonts can't 
automatically mirror neither rotate their glyphs.  So for every SignWriting 
symbol in the symbolset you will have to insert 24 transformed symbols!  
Another problem with fonts is that in a word the letters follow each other 
linearly, in a sign the symbols are just placed relatively from each other.

> 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.
Yes, but this is still putting and not transforming.  It is possible in 
Unicode to insert these transformations, but this requires many new 
constructs in Unicode which can't be understood by normal Unicode programs 
like your browser.

> 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.
This only holds true, if you only use regular Unicode constructs, so a 
programmer can pick a Unicode renderer of the shelf, instead of writing it's 
own.  

> 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.
Yes, but as already mentioned a font for Unicode SignWriting will be either 
huge because it contains every possible transformation of every possible 
symbol or can only be interpreted by a SignWriting program. 

> ...
> 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.
Unicode SignWriting will only be adopted in third party software if it is 
plain standard Unicode.  Which is as already argued far unlikely.  The 
difference between a word and a letter is typographically speaking far less 
then that between a sign and a symbol.
It would be great if SignWriting could be rendered with standard software, but 
we think SignWriting Unicode will come to nothing.  
We think the SVG SWML future is far more brighter.  It would be great if we 
had an SVG symbolset, so we could export in a SignWriter program to SVG, and 
render that with standard software.

Greetings,

        Bart & Steven