Data exchange with SignPuddle Markup Language

[Bill Reese]

Steve,

Drawing upon the idea of using polar coordinates, a path could be traced 
from symbol to symbol.   A collection of paths inherent in a signed 
language along with different origin points could comprise a separate 
alphabet in the same way that Hiragana in the Japanese language provides 
pronunciation information for it's Kanji characters.

In this manner, starting with an origin point designation followed by a 
path designation followed by a list of Signwriting symbols could be all 
that would needed to establish a sequence that then places the symbols 
in their positions within a sign.

Bill


On 5/27/2010 4:05 PM, Bill Reese wrote:
> Steve,
> 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.
>
> Bill
>
>
> 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.
>>
>> Hi Charles,
>>
>> 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.
>>
>> More information...
>> http://www.kfunigraz.ac.at/~katzer/korean_hangul_unicode.html
>>
>>
>> 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
>>
>>
>>
>>
>> To encode this with attachment points, it would look like this...
>> , attachment point 135 degrees, , attachment point 90 degrees, , 
>> return to center, attachment point 225 degrees, , attachment point 
>> 270 degrees,
>>
>>
>>
>> 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,
>> -Steve
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.linguistlist.org/pipermail/sw-l/attachments/20100527/b1905840/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 727 bytes
Desc: not available
URL: <http://listserv.linguistlist.org/pipermail/sw-l/attachments/20100527/b1905840/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 313 bytes
Desc: not available
URL: <http://listserv.linguistlist.org/pipermail/sw-l/attachments/20100527/b1905840/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 209 bytes
Desc: not available
URL: <http://listserv.linguistlist.org/pipermail/sw-l/attachments/20100527/b1905840/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 137 bytes
Desc: not available
URL: <http://listserv.linguistlist.org/pipermail/sw-l/attachments/20100527/b1905840/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 211 bytes
Desc: not available
URL: <http://listserv.linguistlist.org/pipermail/sw-l/attachments/20100527/b1905840/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 140 bytes
Desc: not available
URL: <http://listserv.linguistlist.org/pipermail/sw-l/attachments/20100527/b1905840/attachment-0005.png>