I just finished giving your document a second read over. I
added some comments and remarks and hope that they will be
insightful and also that you get back to me with some of my requests
For some time, I have thought that attaching symbol to symbol
could add additional information to the SignWriting data. I thought
that it might be useful to explicitly state which symbols contact,
or interact (for movement symbols) would be useful for automating
avatar animation and also changing from one receptive to expressive
viewpoints. But I haven't because, defining attach points for all
the symbols is more work than I can do by myself. Then to make use
of the information, we would need to create a new input mechanism
(or a conversion routine and then have someone read them to see if
the relationship were properly inferred) and new rendering engines,
which are also a lot of work. But the idea in itself is appealing.
Author of SignWriter Studio
On 12/6/2012 9:02 PM, Martin Hosken
Just to introduce myself. I'm a script technologist with SIL who has been involved in a number of complex script encoding efforts, adding them to Unicode and producing implementations. I have been involved in the encoding of SignWriting off in the SignWriting in UCS list. It was suggested I join this list to engage more experts on SignWriting in the process of encoding SignWriting layout in Unicode.
I enclose a discussion document with my current thinking on the topic. Warning. It's not an easy read. But I hope it will be worth your effort. If you are an implementer or interested in the technical aspects of how we might linearise a 2D writing system, then please do give it a read and give your feedback. Please also note that there is no intention to rush off and get this added to Unicode. As the paper states, we must do a proof of concept implementation first.
For those of you who are experts in SignWriting. The key issue that this document raises (although it doesn't mention it much) is the question of spelling. When storing a set of symbols that make up a sign, if we want to be able to search for that set again, they have to be stored in a consistent order. The problem with this is that there are 3 different preferred orders:
* keying order
* sorting order
* searching order
Of these 3, the easiest to work around is the searching order. That's an implementation problem, which regular expressions can handle well. But the other two tend to fight each other. The question I have for you as a community is: can we regularise keying order and can we perhaps adapt the sorting order to be a little closer to the keying order. I have presumed that we can in the document, but it would be good if people could review that.
Full disclosure: I am not deaf. I can barely read SignWriting and so will analyse some signs wrongly. I have probably done that in this document. It is entirely unintentional and would value the review.