Re: Complex script editor wish list

On Fri, 19 Sep 2003 12:36:44 -0700, JS Bangs <jaspax@...>
wrote:

>I don't see why you need a new text editor in order to be able to do these
>things. Decent fonts, Unicode support, and some scripts should be able to
>handle it. It seems that the problem lies more with support of Unicode
>than problems inherent in a text editor.
The problem isn't so much Unicode as the font technology. Windows only
supports a very limited set of scripts, like Arabic and Devanagari. Support
for Unicode doesn't imply support for correctly rendering the scripts
encoded by Unicode.

>> So I've been thinking of writing a primitive text editor that can be
>> configured to handle complex scripts.
>
>The thing is, there already exist (at least) two very advanced editors
>that can handle complex scripts: vi and emacs. All that's needed to add
>support for *your* complex script is a relatively small patch.
Vi and emacs can handle complex scripts? I always thought those were just
text-mode editors, but it's been a long time since I saw either of them.
What would be involved in setting one of these up on a Windows system?

>> Clearly, it has to be able to handle ligatures, diacritic placement, and
>> the kinds of contextual substitution that come up in complex scripts. The
>> Kazvarad script has a couple of letters with alternate forms that are used
>> when a long ascender would otherwise run into a nearby letter. Script
>> direction is also important; the Twing script historically used for
>> Nimoryikh is written right-to-left, and the Kazat ?Akkorou and Yortry
>> scripts are written vertically. It would be really nice to support mixed
>> script direction in the same document, but that brings up a whole new set
>> of problems, especially with vertical scripts.
>
>For this, you want LaTeX. Which you can write with one of the previously
>mentioned text editors.
I'm not really interested in printed output so much as just being able to
see the text on the screen.

>> Real-life scripts like Devanagari have complex reordering rules, where a
>> short i might need to be moved to the left side of a syllable at the same
>> time that an initial r- is moved to the end and replaced with a combining
>> mark above the final consonant. Then you've got scripts like Oriya and
>> Cambodian, where a single vowel character might need to be split up into
>> three parts before, above, and at the end of the syllable. So the text
>> display system at least needs to be able to find the boundaries of a
>> syllable and move characters around relative to those boundaries. (Probably
>> one reason the Thai script is encoded differently is that it's not always
>> possible to find the syllable boundaries without dictionary lookups.)
>
>I don't know if these are even things that a text editor should do. In
>Thai, at least, you type the characters in the same order that they are
>written, without regard to pronunciation. An editor that automatically
>reorders your symbols is an interesting idea, but once again can be done
>with a simple script extending an existing editor.
Whether a text editor shoúld do these things is an interesting question,
but if you want to use Unicode internally and display the characters
visually as they should appear in the written language, that's the way
those scripts are encoded. On the other hand, I guess there's no reason an
editor needs to use Unicode internally. It could store things in visual
order and do a conversion to/from Unicode when exporting the file. Keyman
can easily reorder the keystrokes (well, fairly easily; I managed to get a
reasonable Neesklaaz keyboard working, where the Unicode encoding of
Neesklaaz puts the vowel mark _after_ the consonant it's attached to, but
you type it in the order it's pronounced, _before_ the consonant). And the
Unicode guidelines might not make the most sense for certain scripts (like
Neesklaaz).

>I don't want to discourage you from making your own text editor if you
>insist on it, but I think you'll get better and more useful results by
>adapting existing tools.
That's one of the problems with Windows systems; existing tools tend not to
be adaptable. Buying a new system or replacing Windows with Linux isn't an
option at this point.

Reply