[
Alan Kent
22 Wallabah St
Mt Waverley 3149

Alan Kent     (RMIT, Melbourne, AUSTRALIA)
UUCP: {seismo,hplabs,mcvax,ukc,nttlab}!munnari!goanna.oz!ajk
ARPA: munnari!goanna.oz!ajk@SEISMO.ARPA
ACSnet: ajk@goanna.oz
]

			  TALKING THAI

Ever wanted to do a project to show off the real power of the Amiga
compared to all those other inferior machines?  This was not the reason
I started this project, but looking back, it was certainly easier than
it would have been on most machines.  Recently I have been trying to
learn Thai (Why you ask? Well, I knew Pascal, Cobol, Fortran, C, Basic
etc., so why not learn another language!). I have not given up yet, but
I have realised that human languages are a LOT more complex than
computer languages.  To aid myself in learning the language, I thought
it would be useful to write a program to quiz me on the English/Thai
translation of words. For fun I then tried to get the Amiga to speak
the words in Thai so I could listen to what the words should sound
like.  Unfortunately Thai has over 20 vowel sounds, many of which the
Amiga's narrator does not support, so the end result was far from
accurate.  The narrator device is the software that allows the Amiga to
speak.  In this article I thought I would describe some of the
experiences I had in trying to get this program going.

		WRITING SOFTWARE WITH INTUITION

Most of the software I have written in the past has been C under UNIX
and was to be used on normal computer terminals. As a result, the
interface was pretty limited.  The Amiga, as you know, has a much more
powerful interface which can be accessed through a library called
Intuition. This allows the easy use of features such as menus and
gadgets which are controlled by combinations of mouse and keyboard
input.  It is very useful that most of the interface code (such as for
controlling menus) is already written for you.

Briefly, a gadget is Intuition's main form of user input.  There are
actually three main types of gadgets. Boolean gadgets are simply boxes
or images on the screen that you click on (for example, the depth
arranging gadgets in the top right hand corner of windows),
proportional gadgets are basically slide bars and string gadgets allow
text to be entered in a rectangular area on the screen. String gadgets
can be used to accept numbers rather than straight text.  A requester
is a rectangular area that appears, for example, when a program asks
for a filename. Requesters use gadgets to actually accept input from
the user.

Personally, I dislike using menus for commands I use frequently.
Moving the mouse up to the top of the screen, then dragging it down for
the correct entry (the entries usually being packed quite closely
together) can get annoying after a while, especially if you get the
wrong entry and accidently erase the past 20 minutes work!  I prefer
having great big boxes - big so they are very hard to miss - to click
on with the mouse.  As a result, my program ended up using lots and
lots of boolean gadgets all over the screen and no menu bar at the top.
One disadvantage I found in doing this is that if you have too many
gadgets, it can take quite a while to refresh them all. My program
takes about a second, which is just long enough to be annoying.

One problem that stumped me for a little while was how to output error
messages.  My screen for this particular program had ended up so densly
packed that there was no room left for printing error messages
anywhere. I finally realised that I could use a requester for both
error messages and to accept answers to simple yes/no type questions.
(It often takes me a while to see the obvious).  The intuition function
AutoRequester() automatically builds a requester to accept a yes/no
type answer - all the user needs to supply is the size of the requester
and text to go in it.  These requesters are exactly like the `Please
insert disk X into any drive' with `Cancel' and `Retry' selections that
AmigaDOS often generates.  To output an error message, I simply used a
requester with only a `Cancel' selection.  The end result, while simple
to achieve, looks great compared to previous terminal based programs I
had written.

		    A THAI QUIZ PROGRAM

The above is valid for any program that uses intuition.  My Thai quizer
program however added a few more problems.  The program basically
allows both sentences and words to be entered in both English and Thai,
plus the phonetic spelling of the Thai words.  For example the phonetic
spelling of CAT may be written as KAAT (K, AA, T).  There are several
different standards for phonetic spelling, the main difference being
which english letter or letters are used to represent the sound.  The
phonetic alphabet I ended up using is not the same as what the Amiga's
narrator device uses, mainly because the narrator does not have all the
sounds that exist in Thai.  Note that the Amiga's narrator device
accepts all input in phonetics. To make the Amiga speak English
involves using a translator library to convert the English text into
phonetics.

Once words or sentences have been entered, the program can then be used
to either search for a word by Thai, English or phonetic spelling, or
randomly choose words to quiz you on. It does not help with learning
the structure of Thai sentences much, but it certainly does help
learning individual words and common sentences.

Rather than translate the Thai into phonetics myself, I wrote some code
to do it for me. Thai itself, luckily, is basically a phonetic language
- that is the pronunciation of individual characters basically stays
the same (not always of course! that would be TOO easy!).  English was
apparently once a phonetic language, but this is no longer true
(consider the words low and now - `ow' has different pronunciations in
the two words).  The translation of single words at present only works
perfectly about 50% of the time. 40% of the time minor corrections need
to be made.  The other 10% of the time, the translation fails
completely.  If nothing else, the automatic translation reduces the
amount of typing required to enter the phonetic version of the Thai
words.

Translating complete sentences is easier as the dictionary of
pre-translated words can be used to do a word by word translation.  The
translation of complete sentences still has one minor problem in that
Thai does not have spaces between words! It just allrunstogether!

Another problem I came across was that the Thai language has its own
character set. The Amiga luckily provides the ability to handle
different character sets or `fonts' so I was able to design my own
using a font editor (there is one on a public domain disk somewhere and
there will also be one supplied with V1.2 I believe). The font ended up
being 22 pixels high (normal text is usually only 8 pixels high). This
was because in Thai there are lots of symbols that can appear above,
below, to the left or right of characters to change their meaning or
pronunciation and all these symbols had to be included in the character
set. Thai characters also have lots of little loops which makes them
difficult to draw on a graphics screen so the actual characters cannot
be reduced beyond a certain limit.  In total there are about 44
consonants and 33 vowels in Thai, although many of the vowels are
produced by using different combinations of a small number of symbols.

As Thai characters bear no relation to English characters, it is
difficult to map all 77 or so Thai characters to keyboard keys in any
way that could be easily remembered. As a result, I used boolean
gadgets again at the top of the screen which showed what the characters
look like. Entering text involves clicking gadgets with the mouse
rather than using the keyboard.  Entering Thai text can be quite slow
unfortunately, as you have to move the mouse around a lot, but it is
easier than remembering the keyboard layout!  Using this approach means
however that a string gadget cannot be used for Thai input fields.

Outputing Thai characters on a printer also presented a minor problem.
The printer driver provides many useful features for outputing normal
English text, but has relatively poor support for handling different
fonts other than pure ASCII. The solution appears to be to allocate an
area of graphics memory and to draw the characters into it. The final
image can then be output with a `dump RastPort' command to the printer
driver. The easiest way to achieve all this is to create an Intuition
screen only as high as the character set (in my case 22 pixels) with a
single bit plane (only colors black and white are needed) and then to
use Intuition functions such as PrintIText() to output the Thai text
into this screen. Dumping a screen's RastPort simply involves copying
some information from the screen's Screen structure into the printer
request block and sending the request to the printer driver.

		    USING THE NARRATOR

Just for fun, I decided to try and get the program to speak the
phonetic version of the Thai words. I did not really expect to get very
good results (considering the quality of the Amiga's English
pronunciation) but it was fun trying. There were two main problems I
encountered and only partially overcame.

Unfortunately, Thai has got a lot more vowel sounds than English. The
narrator device simply did not know about all the sounds I needed. The
best I could do was either to pick the closest sounding one or string a
few together. As I am not really sure myself what they are meant to
sound like, I cannot be certain of the results.

Thai is a tonal language which means that the pitch of the sounds also
affects their meaning. In Thai there are 5 basic `tones': common, low,
high, rising and falling. In English, when asking a yes/no question for
example, we normally raise the voice at the end of the question (`Are
you well?').  This must not be done in Thai.  Just to make things that
little bit more interesting (or confusing), the duration of sounds is
also important (short or long). Each syllable in a Thai word then has
its own sound (usually consisting of an initial consonant, a middle
vowel and an optional final consonant), a tone, and a duration.  Trying
to get the narrator to speak a multi-syllable word can get quite
tricky!

To be able to get total control per syllable, it was necessary to send
the narrator device one syllable at a time. This unfortunately resulted
in significant pauses between each syllable as the narrator thought it
was the end of a sentence. I have found no way to get around this
problem. Sending a separate command per syllable makes the duration
easy to control.  The common, high and low tones are also simple - just
use the robotic (monotone) voice and change the pitch.  The rising and
falling tones are harder, but are possible by using the natural
(contoured) voice.  Adding a '.' at the end of the syllable (to make it
think that its the end of a sentence) generates a falling tone and
adding a '?' generates a rising tone.

			CONCLUSIONS

The Amiga with Intuition sure makes it easier to do nice interfaces.
It provides lots of easy, ready to use functions to handle gadgets and
menus. What I really would like though is an easier way of designing
the menus, gadgets, windows etc. without having to recompile the
program. I have heard (in other words I really don't know) that the Mac
allows such definition files that can be modified to change the
interface to the program without the program requiring recompilation.
Looking at the latest public domain disks however there seems to be a
gadget editor (egad) which I will have to have examine, and there was a
menu editor on an earlier disk too.

The next things I want to have a go at are the animation routines and a
bit of music. Then I can get onto some serious stuff, like writing a
few games!