To: stik@on-luebeck.de
Subject: Re: [3] STIK: read this RFC and comment back                                    


On Sat, 21 Dec 1996 13:52:04 Martin-Eric Racine <q-fun wrote: 
>
----- snip -----

>>Will this only affect the character-set? so that it matches the ISO-8859
>>characterset? or does it also affect the keyboard map?
>>
>>If it only affects the Character-set and not the Keyboardmap, we will
>>not be able to write with the new characters! therefore you will have
>>to affect the keyboardmap also (do we have to use a seperate program
>>for this?)
>
>This will only replace the fonts, so we can view the proper letter
>for a given 8-bit ascii code. Taking the French example, "e acute"
>will show up when requested as "decimal 233" which is the correct
>ISO 8859-1 code for an "e acute", instead of the 7-bit ascii Atari
>(MS-DOS) "decimal 130".
>
>The keboard layout will have to be remapped through other ACCs,
>such as MK-KBD, that support KBD files.

Can you give an http or ftp site were MK-KBD can be found.
I would like to check it out, but have never seen it.

I also have a program that uses KBD files (UKEX.PRG) which I have long used
to provide a Swedish keyboard layout in MagiC.  My program also allows two
KBD sets to be loaded simultaneously, with hotkey commands to either switch
between them, or enable/disable the 'hidden' one for use with the 'Alt' key.
Anyone interested can download UKEX (with full source) from my homepage.
(The URL is shown in my SIG at the bottom of this mail.)

I should add that this program is a TSR for \AUTO\ and not any ACC.
It works fine for me under all TOS and AES versions I know of (quite a few).


>Why through other ACCs?  Simply because every language has its own
>most often used letters. In French, "e acute" is most often needed
>but German would likely require vowels with "umlaut" the most and
>Scandinavian languages "o ring", "o slash", or in the case of the
>Icelandic variation, "Thorn". This would make it nearly impossible
>to come up with a suitable keyboard layout that satisfies everyone.

So what...?  If the program supports KBD files loaded at startup,
any user can customize it simply by the choice of such files.
But, please, don't urge people to implement such things as ACC's.
The ACC-slot situation is bad enough as it is.


>Also people communicating in more that 2 languages, such as myself,
>would encounter the problem of constantly switching keyboard maps,
>which is to be avoided.

Why ?
This should not be a problem provided the means of doing so is simple
and convenient.  At present my UKEX program only supports two sets of
KBD files, but that would be very easy to expand.


----- snip -----

>>the only problem I can see is that ALL programs that do not support
>>this new characterset and keyboardmap what will happen to them?
>
>As mentionned in the docs, the Atari's default MS-DOS mapping can
>be recalled by a line of code by any application requiring it, but
>note that only the 160-255 range is different from the MS-DOS map,
>when using the ISO-8859-1 layout.

Right, but this is where the 'hotkey' functions of UKEX really come in handy.
Especially if they could also affect the font choice as well as the keyboard.
That would require either an integrated solution, or some common nationality
selector controlling both programs.  This should be a cookie I think.
Possibly your cookie, for example.


----- snip -----

>>therefore I will have problems, if it is NOT possible to turn ON/OFF
>>this new feature that you are going to provide. I hope that you make
>>it possible to turn it off/on by the user some way, and even possible
>>by the programs, ie when running ant-mail antmail turns un this feature,
>>and when I quit ant-mail it also turns it of!

If we use some means, like the UKEX hotkeys, to alter a cookie which in
turn controls both the keyboard and default font selection of programs
started thereafter, this problem disappears completely.  It is also quite
simple for programs to do this (automagically) by accessing that cookie.

It will not be possible to use this means to switch 'default font' for an
APP already running however, since that is only set when the APP opens its
workstation.  Also any program may override the default by using some
other GDOS font, which is quite alright.  Clients intended to support this
feature should find the correct GDOS font numbers to use via the cookie.

This way decent control is achieved even in programs that do not support
this font scheme or even any GDOS fonts at all (they will use default).
And with those that do support it operation is perfect, allowing dynamic
switching between the character sets both manually and 'automagically'.


>>This last one is going to be a problem when running under Multitasking,
>>and not single tasking, since I believe it will be trouble recognising
>>which programs are to be using the feature, and which are NOT to use
>>the feature.

No. Programs written to support this will know when to use the suggested
default and when to override it with the 'real' system font or another
GDOS font.  Programs not supporting the scheme will use either GDOS fonts
of their own choice or the font that was default when they started.
They will not change font dynamically just because the default changes.
(NB: This has been tested extensively with my own font changer.)


>Let's make this clear, 8859FONT will only replace the SYSTEM fonts.
>Should anyone have applications that require the original fonts,
>they can be recalled through a line of code passed to 8859FONT. But
>I suspect multi-tasking users will have a problem with this, when
>running an application that requires the 8859 in parallel to one
>that does not.

Not necessarily.  That depends on _how_ you enforce the system font.
If you do it (like me) with a VDI extension that simply replaces the
default GDOS font choice in the workstation arrays, then there is no
problem.  An APP will either switch to some GDOS font it needs or
stick to the one given as default when it started.

So if you know what mode you use when starting the APPs, they can
then use different modes simultaneously even if unsupportive.
Supportive APPs should know which fonts are appropriate for their
various windows at all times and change only as needed.

The keyboard mapping however is global, so at any single time all APPs
will have the same keyboard mapping.  Actually this difference makes
perfect sense, since there can be many windows, but only one keyboard.


>Please use a different NVDI fontset for each application, if this
>is a problem, or comment back through the list on possible ways to
>address multi-tasking through this TSR.

Oh, we have a terminology problem here.  I'm sure that you mean the
same thing as I do when saying "GDOS font", when you say "NVDI fontset".
I just wanted to clarify that.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
