[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] UTF-8 support



Hi,

On Thu, Apr 27, 2000 at 02:03:33PM +0200, Jo Even Skarstein wrote:
> > 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. 

You can also scale bitmaps but I was actually thinking of vectory
graphics.  The characters in question are the closer, fuller, iconifier,
hider, and the four arrows.  All of them could easily be drawn on the
fly.  If an 8x16 font is used, then you could just as well use the window
elements.

> > 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.

If a box char with a down arrow is used, the resource designer's intention
was most probably to copy the apperance of the window down arrow.  What
should be bad about simply copying the window element then?

> 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.

I agree (although my library did of course work flawlessly ;-) ).  My
proposal: There should be a VDI-based X server and AES calls should be
emulated by X calls.  Designing something better than X may be a good
idea, but making X available for MiNT (coexisting with GEM) would provide
us with an enormous supply of free software (at least those packages
that we can get to run).

Besides, writing an X server is probably a lot less work than thinking of
and implementing a new API for the GUI.

Another possible advantage:  Maybe it would be feasible to write optimized
X servers for some graphics hardware or drivers for new input devices.

> > 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.

Not here.  My system font is a Monaco font but MiNT ignores that on the
console.  Maybe a problem of my graphics card but I always get the system
font from the ROM.

Uhm, I know that there is not always a free choice of mailer at work:  But
is there any way to configure your mailer to write proper linefeeds?  In
your posting there are only linefeeds after empty lines
(i. e. paragraphs).  And what the heck is the "Nextel Epostleser"?

Ciao

Guido
-- 
http://stud.uni-saarland.de/
Send your spam to president@whitehouse.gov and your replies to
mailto:guido at freemint dot de