[sw-l] challenge for programmers - SSS-ID mapping onto Unicode

[Steve Slevinski]

Hi Stuart,

Point taken.

-Steve

Stuart Thiessen wrote:

> 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.
>     <unknown.jpg>
>
>
> 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.
>     <unknown.jpg>
>
>     Rotation only means mathematical rotation with handshapes and some
>     arrows.
>
>
> 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
> that.
>
>     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 communicating SignWriting.
>
> 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.
>
> Thanks,
>
> Stuart