On 06/14/2010 02:15 PM, Asmus Freytag wrote:
On 6/14/2010 9:21 AM, Stephen Slevinski wrote:
Greetings Asmus Freytag,
Plain text SignWriting should be able to write actual sign language,
such as "hello world."
You could equally well insist that it should be possible to express the
opening bar of "twinkle, twinkle little star" in plain text, or write
the "square root of the inverse of a plus b" in plain text.
In both cases, you would be disappointed and find that a markup language
is required, such as MathML, although specifically for math, it is
possible to device an extremely light weight markup language that comes
close to plain text.
It is all too tempting and too easy for discussions of "Why X Should be
Encoded in Unicode" to devolve into "Why X is So Incredibly Useful." In
this case, I don't think that's the point. Unlike some other proposals,
I think it is clear (to me, anyway) that SignWriting has a fairly solid
user-base and also an important use (transcribing signed languages,
which don't really have too many other ways of being transcribed.
Things like HamNoSys are also not encoded yet). Here, the question is
more a matter of "given that SignWriting is nifty, does it qualify as
plain text?" Or even "Does the way SignWriting does its thing map well
to the way Unicode does things?" If it does not (and cannot be made to
do so), then no matter how useful SignWriting is, it may simply not be
encodable. It's not because it doesn't deserve to be, and yes, that
would really be a bummer because it would relegate signed languages to
second-class, but Unicode has its limitations, and SignWriting may well
be beyond its capabilities.
(That said, I find myself thinking that it *should* be possible to align
Unicode and SignWriting. But I recognize that it might not be.)
This does not work for me.
I dislike the idea of requiring a higher level protocol in order to
encode plain text SignWriting. I have used CSS to change the color and
size of SignWriting. I chose not to include color or size in the plain
text representation of SignWriting because color and size do belong in
the higher level protocol.
Color is explicitly out of scope for Unicode. Glyphs are monocolor.
Not all streams of concrete small integers are ispso facto plain text,
even though you can map these integers to the private use space.
I guess you would need to establish a distinct and independent meaning
for each code-point, which would have to be something more specific than
"...and then you give the x-coordinate."
For the future, I am considering a browser plugin that will detect and
render SignWriting character data. A regular expression could scrape
the appropriate PUA characters. Another regular expression could
validate that the characters represent valid structures. Then the
SignWriting display could be built using individual symbols, completed
signs, or entire columns.
In other words, a layout engine.
Is there such a thing as SignWriting without a layout engine? I guess
the same question could be asked about Musical notation (though I think
it probably could have been coded as plain text. See also
http://abcnotation.com/ for a very powerful musical notation using only
ascii, but decidedly *not* plain-text in nature).
If SignWriting cannot be successfully used except with 2 fonts, then I
see little need for standardizing the code. What you describe is a
private use scheme, even though the private group may have many members.
I'm not sure I agree with this. Just because only two fonts are out
there so far, and the character-shapes perhaps allow a little less
flexibility than some, doesn't mean that other fonts aren't possible.
Nor is the multiplicity of fonts a requirement for encoding.
SignWriting has the unusual requirement of a 2 color font. One font
color for the line of the symbols and another for the fill. The fill
is needed when symbols overlap.
Hmm.
AFAIK, Unicode can't do color. I remember someone mentioning that once.
But someone who knows the exact rules can explain better.
I think it will help when your proposal is ready for review so people
will understand just what it is you are suggesting and can judge how
much (if at all) it conflicts with Unicode's capabilities.
~mark
