Analyzing SignWriting text structure

[Daniel Noelpp]

> Well, before Unicode, computer programs were trained to think about
> different character sets, etc.  So maybe we can figure out a way for SW
> Java to understand it is opening a DOS file as compared to a SW Java
> file using SSS-2002 or SSS-2004.  Off the top of my head, the easiest
> way to do that is to make SSS-1999 or greater documents have a
> version number at the beginning of the file.  If there is no version
> number, it is a SW DOS file. Then SW-Java can use the SSS-1995
> to open and convert to SSS-1999.  That would be
> simple enough maybe, Daniel?

Hello Stuart, hello Valerie and friends!

That's no problem with version numbers. There's already a version
number. By the way I think I keep asking stupid questions...
Everything is there... Sorry, Valerie.

By the way, why do we have "variations"?

I am trying to model the signs, that means I develop objects:

- BaseSymbol (SSS-1999 has about 250 base symbols)
- Symbol (which is the varied, filled and rotated BaseSymbol.
There are about 16 thousand different symbols).
- Sign (which contains symbols and their locations within
the sign)

These objects are exactly as in SignBank and SymbolBank,
that means, they carry the same properties and names.
For a BaseSymbol you can ask for its category, its group
but not its image. For a Symbol you can ask for its BaseSymbol,
its variation, its fill, its rotation and its image.

The problem is to translate the different SignWriting formats
(SSS 1995 from SignWriting DOS, SSS 1999 from SignWriting
Java and SWML from SignEdit) into the internal representation
of the new program and from the internal representation
back to SSS 1999 and SWML.

Is this a good idea?

Why do I this? In the old SignWriter Java the code to model
the SignWriting and reading from files and rotating images
are intermingled. And I have the vision to integrate the
Symbol Bank into the SignWriter.

Daniel