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

Thu Dec 9 19:57:05 UTC 2004

NOTICE: I am going to discuss some technical aspects related to Sandy's
comments, so if you aren't interested in the technical "mumbo-jumbo"
then you might want to skip this email. ;)

The key to what you have described is the ability to create a linear
representation of a SW text. As we have discussed before with Unicode
(and I am still working on developing partnerships to see if we can get
a Unicode project going), but simplistically put, we need four
components to make what you are talking about possible:

1) Unicode font ... Valerie and Michael Everson have fought for this
already, so we just need to make it a reality ...  Valerie's IMWA is
what we need to establish the Unicode numbering.  You certainly aren't
the first to bring up the question of whether we should have the
symbols "pre-assembled" or composed on the fly (as it were). Unicode
could embrace either approach if I understand correctly.  The challenge
with on-the-fly composition is that we create another level of
complexity for the typist who must compose the symbols and the sign ...
some software could help with that. So, at this point, either is
technically possible.	

2) IME (Input Method Editor) ... This could be like the SignEdit
approach or the SW-DOS approach or some mixture or modification of
either/both. This would be the "interpreter" between the 2D approach
that the typist will expect and the linear representation that the
computer would want.

3) Linear Representation ... This is probably the controversial part
because I expect that there will be as many linear representation
proposals as there are SWML proposals :). But this is what is the
linchpin of what we need to do. We have to figure out how to make it
work. Unicode for Chinese does include various "code" symbols that
indicate how to assemble some composite characters. That might also be
possible to do here. I have also wondered if a modification of
Valerie's Sign Spellings for the FileMaker SignBank might be a way to
go.

4) Renderer ... This would be the engine that the software could depend
on to translate the linear representation back to a 2D representation.
The engine could rely on certain rulesets that would help it interpret
the linear representation. There are a couple of possibilities here as
well ...

Now, I'm not saying this because I am the expert. I am saying this
because this is how I understand the challenge and it helps me to put
it in perspective. I think it may be important to discuss the linear
representation and then we can move to the other components ...

What do you think?

Stuart

On Dec 9, 2004, at 11:57, Sandy Fleming wrote:

> Val wrote:
>
>> I think a lot of you may have lost the idea of what the IMWA is....It
>> is not meant for small computers or for tiny little software programs.
>
> Thanks, Val, that comes as a breath of fresh air!
>
> But it got me thinking about what other things we perhaps have to
> check to
> see if we're using them inappropriately, and I've found that this may
> strike
> at the heart of our "software problem", ie the fact that we are having
> to
> wait a long time for programmers to produce good editors and sign
> processors.
>
> 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
>
>
>
>
>
>
>
>