Re: [MiNT] UTF-8 support

[Jo Even Skarstein <jo-even.skarstein@stryn.online.no>]

Guido wrote:

> > You don't have to wait, if you use N.AES you can use a
> font with the old Atar$ 
> But what do I do if I want to or have to use another font for text labels
> in GUI elements? For example I want to display a dialog

I didn't think of that.

> two box chars showing an up and a down arrow.  It would
> be easiest if the
> AES simply replaced all occurrencies of characters <SPACE
> by their
> graphical representation in the Atari codeset.  That

You mean replacing them with bitmaps? That will only work as long as you use the standard 8x16 fontsize. Since the AES-objects are sized in characters, I think it's best to use characters in the boxchars as well. 

> would also ensure a
> consistent look and feel, because the hand-tailored
> sliders would have the
> same appearance as the window sliders.

I don't think this will look any good, now that "winframes" has become so popular.

> Another drawback of the AES is that the graphics are not
> separated by the
> text, they both come from the binary resource file.  A
> couple of years ago
> I have written a package called xgemtext which was an
> approach to solve
> the problem.  A program allowed to extract all strings
> from the resource
> file and put them in a pseudo C file where the strings
> were properly
> marked for further processing by GNU gettext.  At runtime
> you could use a
> library that comes along with gemtext to "translate" your

I remember that I took a look at xgemtext, and while it's a neat idea it's severely restricted by the AES. The AES is simply not designed for this. I would say that the only proper way to get proper font-support and true internalization is to discard the old object/resource-structure and design something new.

It could be based on the old design (which isn't that bad really), but there are atleast one thing it must support: Some method to align siblings. Without this you really can't use dynamic strings/labels. This could perhaps be done by adding horizontal and vertical rulers to all objects, and position childs with "tabulator marks" instead of absolute offsets.

If you did this you could easily change any label, and simply make room for it by moving the "tabs" and adjusting the length of the rulers. Doing this recursively is a no-brainer and would clean up all dialogs nicely.

Naturally, this will only work with applications specifically written for this object-structure, but as I see it this is only an advantage. There are so many other things you could add to a new AES/object-structure that would really make things easier:

1. Ditch those &%#"¤#¤% userdefs, and replace them with loadable "controls". This would not only be safer than having the AES running application-code, but it will also make it a lot easier to share AES-extensions. This could simply be implemented today by using SLBs.

2. Since the positions of the objects are determined by rulers instead of absolute x/y-positions, we no longer have to use characters in boxchars. So ditch the boxchars and use icons instead. Also, odd fontsizes and proportional fonts would no longer be a problem.

3. Some things like popup-lists etc. are designed by placing a framed string-object next to a boxchar. This is no longer needed, add proper objects for this instead. They could even be realized with (1), allowing coders to replace current objects with modified ones according to their own taste.

4. Support for Unicode, UTF-8 or whatever you like.

> Finally we have the console font.  As far as I remember you can already
> change the fonts for virtual consoles.  The same is needed for the system
> console handled by the kernel.

Today you can easily do this by simply replacing the VDI systemfont. I can't see any problems in letting the kernel select any other font either, as long as a GDOS is present and the selected font is of the correct size.

Jo Even Skarstein