Data exchange with SignPuddle Markup Language

Thu May 27 20:17:21 UTC 2010

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.  

Charles

________________________________
From: Bill Reese <wreese01 at TAMPABAY.RR.COM>
To: SW-L at LISTSERV.VALENCIACC.EDU
Sent: Thu, May 27, 2010 4:05:12 PM
Subject: Re: Data exchange with SignPuddle Markup Language

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/%7Ekatzer/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/f8ca672f/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/f8ca672f/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/f8ca672f/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/f8ca672f/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/f8ca672f/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/f8ca672f/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/f8ca672f/attachment-0005.png>