<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Charles,<br>
<br>
I figured this was an old idea.<br>
<br>
It would be interesting to map attachment points and their placement. 
Perhaps two "circles" of attachments points could be used - one circle
of 8 points at a location halfway between the outer circle and the
symbol's centroid that's rotated 22.5 degrees from the outer group of 8
symbols.  Then, of course, there'd be an attachment point for symbols
in a face that corresponds to the center of the face.   This could get
interesting ...  :-)<br>
<br>
Which begs the question, if a symbol isn't "attached" then is it placed
at all?  That seems to lead to the idea of some symbols being
independent - without a need to either attach or have attachments to
other symbols - the index hand, for instance - which could also be
dependent, depending on context.  Other symbols, like arrows, could
always be dependent.   So that, when typing, you would need to place an
independent symbol first before typing it's dependent symbol and the
relationship would be infered that the dependent symbol is attached to
the independent symbol typed before.   <br>
<br>
Which attachment points are used could be minimized by rules that
establish location.  For instance, an dependent arrow that points up
and right would be attached by the points in it's lower left quadrant
to a point in the upper right quadrant of it's independent symbol.<br>
<br>
Similarly, conjunctive symbols, like the one indicating that both hands
move at the same time, could be attached to the first independent
symbol placed (I'll call it the primary symbol) and the second
independent symbol, the secondary symbol, could be automatically
attached at the opposing attachment point of the conjunctive symbol. 
In fact, since most signs that involve simultaneous hand movements have
the same handshape for each hand, the secondary symbol may
automatically be chosen to be the same the primary symbol with an
option to over-ride.<br>
<br>
As I said ... this could get quite interesting ...  :-)<br>
And I'm probably spinning wheels on something that's already been
thought out before.  <br>
<br>
Bill<br>
<br>
<br>
Charles Butler wrote:<br>
<blockquote type="cite"
 cite="mid20040604155244.93758.qmail@web13707.mail.yahoo.com">
  <pre wrap="">Hey there Bill and Val,

Regarding "attachment points".  I know that in typing
SW DOS, you have a key that goes to 8 points around a
given SW character.  If this were to go to 16 points
instead, for example, in a slightly larger circle, or
even at those shade points between 45 degrees (22.5
degrees) it might, I say might be able to get "good
enough to live by" SW vocabulary down.  Right now, in
addition to the 8 points, you have your arrow keys to
get specific hands or symbols overlapping exactly as
you want them visually to appear.  With so many
contact points on the face, and so many between hands
and various rotations, the interlocking 16 for each
character would make an interesting programming
expansion that could, conceivably, make True Fonts
adaptable.  If Chinese can do it, SW ought to be able
to do so.

Charles


--- Bill Reese <a class="moz-txt-link-rfc2396E" href="mailto:wreese01@TAMPABAY.RR.COM"><wreese01@TAMPABAY.RR.COM></a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Val,
I did a search for TrueType font generation, just to
see what it
entails.  On the way, I came across an article on
Microsoft's site about
International Windows and how they developed the
ability to show
different language fonts on the same machine using
something they call
Uniscribe.  The article is very complex and the
subject matter is new to
me, but it was interesting that it sounded very
similar to some of the
papers I read from the Lisbon conference.  Here's
the link:

    </pre>
  </blockquote>
  <pre wrap=""><!----><a class="moz-txt-link-freetext" href="http://www.microsoft.com/typography/developers/uniscribe/default.htm">http://www.microsoft.com/typography/developers/uniscribe/default.htm</a>
  </pre>
  <blockquote type="cite">
    <pre wrap="">Also, in reading a bit further on the subject, I
came across the need in
some fonts to have what they call "attachment
points" for such things
like diacritical marks - which are usually either
above or below the
rest of the characters in the fonts.  That got me to
wondering if there
could be attachment points for SignWriting symbols.
If each symbol was
surrounded with 8 invisible attachment points, it
could, theoretically,
snap to one of the attachment points of an adjacent
symbol.

At the moment, the symbol placement within the
character box is
restricted by the number of pixels that the box
represents on the
screen.  This allows us to put symbols in a
seemingly infinite number of
arrangements.  If we had attachment points instead,
while the number of
arrangements wouldn't be infinite, it may be enough
for the combinations
we need.  Perhaps 16 attachment points would be
needed, but you see the
concept behind it is to provide a way to logically
order the symbols in
their spatial relationship.   You might even be able
to infer a
relationship based on attachment points - that if a
symbol, say an
arrow, is attached to a hand symbol, then it means
that the hand is
what's moving.

Just a couple thoughts,
Bill


Valerie Sutton wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">When I was working with Unicode specialist Michael
      </pre>
    </blockquote>
    <pre wrap="">Everson, years ago,
    </pre>
    <blockquote type="cite">
      <pre wrap="">Michael told me that there would be no problem to
      </pre>
    </blockquote>
    <pre wrap="">place SignWriting
    </pre>
    <blockquote type="cite">
      <pre wrap="">into Unicode, but there were three issues...The
      </pre>
    </blockquote>
    <pre wrap="">first is funding to
    </pre>
    <blockquote type="cite">
      <pre wrap="">develop all the TrueType fonts for the huge
      </pre>
    </blockquote>
    <pre wrap="">symbolset...that is a big
    </pre>
    <blockquote type="cite">
      <pre wrap="">task and unfortunately the first obstacle. The
      </pre>
    </blockquote>
    <pre wrap="">second is the politics
    </pre>
    <blockquote type="cite">
      <pre wrap="">with the world standards...That has already been
      </pre>
    </blockquote>
    <pre wrap="">somewhat solved, since
    </pre>
    <blockquote type="cite">
      <pre wrap="">Michael has already gotten written acceptance for
      </pre>
    </blockquote>
    <pre wrap="">a SignWriting Unicode
    </pre>
    <blockquote type="cite">
      <pre wrap="">standard from the ISO (an international
      </pre>
    </blockquote>
    <pre wrap="">organization that sets world
    </pre>
    <blockquote type="cite">
      <pre wrap="">standards)...hopefully, even though it has been
      </pre>
    </blockquote>
    <pre wrap="">several years now,
    </pre>
    <blockquote type="cite">
      <pre wrap="">since we received that, the door will still be
      </pre>
    </blockquote>
    <pre wrap="">open when someone
    </pre>
    <blockquote type="cite">
      <pre wrap="">finally works officially on Unicode. Once the
      </pre>
    </blockquote>
    <pre wrap="">first and second phases
    </pre>
    <blockquote type="cite">
      <pre wrap="">are finished, there is a third phase...The
      </pre>
    </blockquote>
    <pre wrap="">programming of how the
    </pre>
    <blockquote type="cite">
      <pre wrap="">TrueType fonts would work, to make it possible to
      </pre>
    </blockquote>
    <pre wrap="">type SignWriting with
    </pre>
    <blockquote type="cite">
      <pre wrap="">them as efficiently as we do in SignWriter
      </pre>
    </blockquote>
    <pre wrap="">DOS...or maybe even better
    </pre>
    <blockquote type="cite">
      <pre wrap="">that SignWriter DOS. I know that most people do
      </pre>
    </blockquote>
    <pre wrap="">not realize that we can
    </pre>
    <blockquote type="cite">
      <pre wrap="">type directly in SignWriting, but we can if you
      </pre>
    </blockquote>
    <pre wrap="">know how to do it, and
    </pre>
    <blockquote type="cite">
      <pre wrap="">getting Unicode to function on that level will
      </pre>
    </blockquote>
    <pre wrap="">need some programming. I
    </pre>
    <blockquote type="cite">
      <pre wrap="">believe that Guylhem's paper is about an idea for
      </pre>
    </blockquote>
    <pre wrap="">Unicode
    </pre>
    <blockquote type="cite">
      <pre wrap="">implementation...and there are other ideas
      </pre>
    </blockquote>
    <pre wrap="">too...People seem genuinely
    </pre>
    <blockquote type="cite">
      <pre wrap="">interested in the programming aspects in step
      </pre>
    </blockquote>
    <pre wrap="">three...But it is
    </pre>
    <blockquote type="cite">
      <pre wrap="">completing step one that scares me ---There are a
      </pre>
    </blockquote>
    <pre wrap="">lot of symbols to put
    </pre>
    <blockquote type="cite">
      <pre wrap="">into TrueType!

      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
</body>
</html>