Towards Unicode Layout

[Martin Hosken]

Dear All,

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.

Yours,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: discuss_2.pdf
Type: application/pdf
Size: 203237 bytes
Desc: not available
URL: <http://listserv.linguistlist.org/pipermail/sw-l/attachments/20121207/713c2476/attachment.pdf>