Fixing a fundamental flaw in Binary SIgnWriting

[Adam Frost]

I know that this will seem small for most people as it won't really  
affect people unless they are in the coding level of things, but I  
have to agree that this change is best even when it may be hard for  
some to change with. (Like my poor blog that I have not been keeping  
up even though it is on my list. HA!) I am sure it will all work out  
for the best. Thanks for giving a heads up. ;-)

Adam

On Jun 1, 2010, at 2:00 PM, Valerie Sutton wrote:

> SignWriting List
> June 1, 2010
>
> Hello Steve -
> You are such a generous and brilliant programmer, and we are  
> grateful for all your hard work. This sounds like a good change  
> towards possible Unicode acceptance someday and I think it is  
> wonderful!
>
> For all the programmers out there, stability with the symbols and  
> coding is coming soon - This is apparently a necessary change, and  
> it is Steve who has chosen to do this, and I am following his lead  
> willingly ;-)
>
> And thank you, Steve, for your caring and sharing with everyone -  
> you really create magic for us daily... There have been positive  
> responses on my Facebook page about the new SignWriting Wiki today -  
> I was really pleased to see it -
>
> SignWriting Wiki
> http://www.signbank.org/wiki
>
> Val ;-)
>
> ------
>
>
> On Jun 1, 2010, at 1:49 PM, Steve Slevinski wrote:
>
>> Hi List,
>>
>> This is a technical discussion.  Nothing is going to change  
>> regarding the writing system.  The change is only data related.
>>
>> Back in 2008, I made a poor design choice for Binary SignWriting.    
>> I needed to define what was a character for the encoding model.  I  
>> decided that each symbol should be a character.  Some others  
>> (Stuart Thiessen, Michael Everson, members of the WLDC, ...)  
>> thought that each BaseSymbol should be a character with an  
>> individual symbol being defined as a BaseSymbol character with one  
>> or two modifying characters.
>>
>> Encoding with symbol characters seemed the better choice, rather  
>> than using 3 times the amount of data to say the same thing.  I was  
>> wrong.  My choice made searching by BaseSymbol much more  
>> difficult.  I was forced to pre-process the data before I could  
>> search.  This was wasted effort.  I realized the error of my ways  
>> when I was reading a discussion of searching with Unicode.
>>
>> I need to fix my poor design choice and reencode the ISWA 2010 with  
>> BaseSymbol characters and modifiers.  I then need to refactor the  
>> character encoding model.  This should be a quick fix I'll have  
>> ready by Friday, but it changes BSW once again.  Hopefully for the  
>> last time.
>>
>> On the bright side, this makes it easier for inclusion in Unicode.   
>> With my previous encoding, I required an entire Unicode plane of  
>> 65,000 characters.  With the new encoding, I only need 1,280  
>> characters.  This is a much better number.
>> Years ago, Michael Everson worked with Unicode for the tentative  
>> acceptance of SignWriting into the standard.  If you look at the  
>> Unicode roadmap for the Supplementary Multilingual Plane, you'll  
>> see that Sutton SignWriting has 4 rows set aside awaiting a  
>> proposal.  These 4 rows represent 1024 characters.  With the new  
>> encoding, I can create a proposal that requires 5 rows.  Much more  
>> reasonable that an entire plane.
>> http://www.unicode.org/roadmaps/smp/
>>
>> Sorry to any and all programmers / users this will inconvenience,  
>> but it is a needed change.
>>
>> Regards,
>> -Steve
>>
>