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?...
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
Moving the fill and rotation characters up 14 codepoints shouldn't
be a problem.
[log in to unmask]"
On Apr 29, 2011, at 11:45 AM, Steve Slevinski wrote:
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]
Rotation-1 [removed from code chart]
A second proposal would include the 2 remaining control characters to complete the set.
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