ISWA 2010 data change for proposed Unicode string
duncanjonathan at YAHOO.CA
Fri Apr 29 19:49:11 UTC 2011
On 29/04/2011 1:02 PM, Valerie Sutton wrote:
> Steve and Jonathan -
> Maybe we shouldn't jump so fast, until we really know what happens with the first Unicode proposal. The official presentation of it has not happened yet - It is happening in May and then a second presentation in June, and in-between the two presentations there may be some re-writes and requests for changes - so why not let everything wait a little before jumping too fast. Let's see what the meetings produce. You never know, until the final vote is in...we do not know anything for sure yet - Just my thoughts - Both of you are going to so much work in advance and I want to be sure you don't do a lot of work before we really know what the final decision is - these things take time when committees are involved - so please do not rush to change your software yet - can you work on other things that are not related right now?...
> Val ;-)
I doesn't affect what I've programmed so far. It will influence the
way I write the code for reading and writing SPML. Today I am working
on other issues so this is OK for now. But the next piece of code I
want to work on is SPML. Because until then, it would make it difficult
to import and export data between SignWriter Studio and SignPuddle.
Do you think we could agree both implement the SPML with the Fill-1
and Rotate-1 characters now as if second proposal had gone through, and
should the second proposal actually get refused, maintain that format
for exchange of data until we both switch over to first proposal
implementations which are slightly more complex to program?
Moving the fill and rotation characters up 14 codepoints shouldn't be a
> On Apr 29, 2011, at 11:45 AM, Steve Slevinski wrote:
>> Hi Jonathan,
>> On 4/29/11 1:04 PM, Jonathan wrote:
>>> Not only does the first proposal make it hard sort the entries but it will also be harder to parse because the symbol with sometimes be 1 character long, sometimes 2 and sometimes 3. So extra checking has do be done to verify if the next character is the start of a new symbol or a fill and or rotation modifier.
>> I agree; however, removing these characters from the initial Unicode proposal may be required to get approval from the Unicode committees.
>> I understand the potential annoyances and problems for programmers who do not use these codepoints.
>> My previous email was unclear on the new codepoint assignments. They should be as follows.
>> The first proposal will be as follows:
>> Fill-1 [removed from code chart]
>> Fill-2 U+1DA9B
>> Fill-3 U+1DA9C
>> Fill-4 U+1DA9D
>> Fill-5 U+1DA9E
>> Fill-6 U+1DA9F
>> Rotation-1 [removed from code chart]
>> Rotation-2 U+IDAA1
>> Rotation-3 U+IDAA2
>> Rotation-4 U+IDAA3
>> Rotation-5 U+IDAA4
>> Rotation-6 U+IDAA5
>> A second proposal would include the 2 remaining control characters to complete the set.
>> Fill-1 U+1DA9A
>> Rotation-1 U+1DAA0
>> With the first proposal, we may be able to move forward with wide spread consensus.
>> I will be working off of the second proposal, so I will continue to use the Fill-1 and Rotation-1 characters in my data and code libraries. The only change for my data will be to advance the fill and rotation codepoints by 14.
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 9.0.894 / Virus Database: 271.1.1/3604 - Release Date: 04/29/11 00:34:00
* _ ____ *
* /\ | | (| \ *
*| | __ _ _ __, _|_ | | __, _ _ | | _ _ __ __, _ _ *
*| | / \_/ |/ | / | | |/ \ / | / |/ | _| || | / |/ | / / | / |/ | *
* \_|/\__/ | |_/\_/|_/|_/| |_/\_/|_/ | |_/ (/\___/ \_/|_/ | |_/\___/\_/|_/ | |_/*
* /| *
* \| *
email: duncanjonathan at yahoo.ca <mailto:duncanjonathan at yahoo.ca>
joyoduncan at gmail.com <mailto:joyoduncan at gmail.com>
SignWriter Studio <http://www.signwriterstudio.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sw-l