[sw-l] Are We Going in the Wrong Direction?

[Valerie Sutton]

SignWriting List
December 9, 2004

Thank you, Sandy, for these ideas and please know they are appreciated.
I think that some of them can only come about because of the past
computer programs that have shown you these issues...so every
generation of programmers learns from past programs and moves
forward...I look forward to seeing your new programs in the
future...and in the mean time, I hope I can provide you with a clean
IMWA that can then be honed down into a smaller symbolset for you
later, perhaps in 2005, but definitely by 2006.....Val ;-)

----------------------------


On Dec 9, 2004, at 9:57 AM, Sandy Fleming wrote:
> I'd like to look at some examples of things that I think some of us
> may have
> taken for granted when there are better ways of doing things. The
> result of
> this was surprising to me: it seems to show that our software problems
> are
> caused not so much by the difficulty of writing SW software as the
> fact that
> we're using some of our best ideas inappropriately. This has enabled
> me to
> address the "software problem" on two levels: one being that with a
> fresh
> look at sign storage and display we could make software a lot easier to
> write; the other being that if we could take it a little further we
> could
> even use existing programs (such as Microsoft Word, or even more
> programmer-friendly, OpenOffice) for SignWriting.
>
> Here are some of the areas where I think misuse of concepts could hold
> us
> back (other than the IMWA, which Val has already addressed)...
>
> Lanes
> =====
>
> Is having special features and special SWML elements for expressing
> lanes an
> unnecessary complication for programmers?
>
> It would be a lot better if we could simply select and move groups of
> symbols around together (rather than just one symbol at a time). We
> could
> then dispense with SWML support for lanes and leave it up to the user
> to
> position the sign in the lane he wants - or indeed exactly where he
> wants in
> the column. A programmer optionally could provide a way of allowing
> the user
> to snap signs into the "standard" lanes, but I think storing the lane
> information should be in the document introduces problems which I'll
> explain
> below.
>
> Signs
> =====
>
> An unquestioned aspect of the software we have at the moment is that
> the
> software whould store symbols grouped in signs. But is this grouping
> necessary for storing SignWriting texts in a document?
>
> It would be simpler to introduce a "space" character or gif to the
> IMWA -
> like any other punctuation mark but blank - and express a SW document
> as a
> string of symbols, including their coordinates (I would suggest
> relative
> coordinates rather than absolute) and let the divisions between signs
> be
> indicated simply by the presence of a space.
>
> At this point you may begin to see the direction I'm heading: I'm
> asking,
> "What if we steered things so that stored SW text behaved more like
> the text
> files (strings of characters) used by software for processing
> oral-language
> texts? Then it might become possible to use oral-language processors
> and
> algorithms to handle SW texts, instead of having to write our own
> software
> from sxratch, as we're doing at the moment."
>
> This also shows what's bad about storing lane information in the
> document:
> it makes it harder to treat our SW texts in the same way as
> oral-language
> texts, making it harder to use existing oral-language software for SW.
>
> SWML
> ====
>
> SWML is fine as a dictionary storage format (something like the way
> oral-language dictionaries do well with their own flavours of XML),
> but is
> it really suitable for storing documentation?
>
> The way SWML has XML elements for storing both signs and symbols is
> analogous to an oral-language text system that has XML elements for
> storing
> words and characters individually. Modern word processors do often
> store
> text as XML but the XML doesn't go down to word or character level.
> Although
> XML storage thus causes the document files to be much larger, with
> SWML the
> bloat for large documents would be really enormous.
>
> The structure of SWML also excludes the possibility of storing SW
> texts in
> anything resembling the strings of characters normally used for
> oral-language texts, and so makes the use of oral-language software for
> SignWriting impossible.
>
> So what should we be doing?
> ===========================
>
> Here's a possibility.
>
> Supposing we had SW symbols created as fonts, preferably unicode, or
> failing
> that, as a specially-created SW symbol font. Failing that, the
> gifs/pngs
> from a subset of the IMWA itself might have to do, but for the sake of
> the
> example, let's imagine we have a font. This font includes a "space"
> character as described above, so that signs can be indicated simply by
> using
> a space or other punctuation mark to separate sequences of symbols,
> much as
> space and punctuation characters separate words in oral-language texts.
>
> This would mean we could simply use any oral-language word processor
> or text
> editor to create SW documents.... except for one thing! Which is that
> we
> also have to be able to indicate where exactly each symbol is to be
> placed
> in two dimensions. I think that this can be arranged, though it may
> involve
> some modifications to existing word processors and text editors, just
> as
> they once had to be modified to cope with right-to-left and vertical
> texts.
>
> We might be able to persuade the writers of the software to implement a
> facility to allow us to place characters (ie symbols) anywhere - after
> all,
> it would be an interesting enhancement for oral-language text features
> as
> well. If we're even luckier there may be some program that already
> allows us
> to do this (LaTeX, for example?). If not, then instead of our
> programmers
> having to write sign processors from scratch, they could obtain open
> source
> word processors and adapt them themselves.
>
> I've thought this through in more detail - the use of
> vertical/horizontal
> columns and relative positioning of symbols, and a standard ordering
> for
> symbol sequences. But perhaps this is a good place to stop because
> that gets
> a bit technical and I'm hoping non-programmers will read this too!
>
> I appreciate that it might be up to me to write these things (proof of
> the
> pudding, etc) if no-one else cares to, but I thought it was worth
> saying all
> this because I think any programmer working on a SW project should be
> aware
> of these issues, so that they don't waste lots of time programming
> things
> from scratch when there's something available that could be made to do
> it
> already.
>
> Sandy
>
>
>
>
>
>