I am curious as to how you wrote the sequential sentence below with SW symbols imbedded in a straightforward English sentence when I can't get the symbols to actually print in a sentence to save my life. If you can imbed in an email, why can't I imbed in an Excel file without being very tedious in looking up every single sign, copying a graphic into a separate graphic file, importing that graphic into the Excel file and sizing it multiple times.
I thought that computers were supposed to do repetitive tasks like this, so I am not very confused.
From: Bill Reese <[log in to unmask]>
To: [log in to unmask]
Sent: Thu, May 27, 2010 4:05:12 PM
Subject: Re: Data exchange with SignPuddle Markup Language
The attachment point way you mention seems to be a polar coordinate system rather than the cartesian coordinate system you're using right now. It lacks the distance specification, which would need to be related somehow to the symbol it's attached to. So I would agree that using a different coordinate system to define attachment points is probably not much different than defining symbol origin points using cartesian coordinates. However, the one advantage it seems to have is establishing a relationship between symbols. In theory, this
would allow you to place the first symbol in a sign spelling sequence at a known origin point and then traversing through the polar coordinates from one symbol to the next in a sequential manner.
On 5/27/2010 12:42 PM, Steve Slevinski wrote:
Charles Butler wrote:
How is Hongul (Korean) encoded. I thought it was spacial characters merged to look like graphics, not a corpus of words. There are only 20 letters in Korean, yet it does print looking like ideographs.
There are 11172 different Hangul. These are created from 68 different Jamo shapes. The Jamo shapes are listed sequentially and specific constructions rules are used to create Hangul based on the sequential order of the Jamo.
This is a complicated exception to the idea of a character is a letter or a pictograph. In the case of Hangul, a pictograph is represented by a combination of characters. The same technique is used for accented characters like "é", which can be a combination of the letter "e" followed by the accent character.
Charles Butler wrote:
I have just looked at the Wikipedia article on Hongul rendering using Unicode, and what the unicode font system has to do to assemble a word (merging more than one character in a set square). If Hongul can do it with a limited character set (around 240) then there is no reason that SignWriting cannot define itself with a character rendering.
The reason is that Hangul uses construction rules and SignWriting uses spatial position. When one Jamo is followed by another Jamo, there is a specific rule that is applied. In SignWriting, if a hand symbol is followed by a movement arrow and then a facial expression, there is no specific rule that can be used to create the sign.
The only possible way to get this to work would be with the idea of attachment points, where an additional character is placed between 2 symbols to explicitly state how to symbols are joined. However, this has
the complication of terminal ends, such as when both hands are involved.
Let's take the example
[log in to unmask]">
To encode this with attachment points, it would look like this...
[log in to unmask]">, attachment point 135 degrees, [log in to unmask]">, attachment point 90 degrees, [log in to unmask]">, return to center, attachment point 225 degrees, [log in to unmask]">, attachment point 270 degrees, [log in to unmask]">
I am convinced that the Hangul construction technique is inadequate for SignWriting; however the Hangul technique may be a good starting place for future development.
I am convinced that we can not make assumptions of symbol
placement based on symbol order alone.
I am unconvinced that the idea of attachment points will work or is worth the effort.
For what it's worth,