On Thu, Feb 14, 2002 at 09:14:05PM +0100, Marcus Brinkmann wrote: > THAT makes me thinking! I am running out of time, but I just had this hell > of an idea: If we would use UTF-8 throughout, we would end up with the vga > backend receiving UTF-8 characters. Now it can do one of two things: The > boring way to handle this is to require a list of 256 characters that it > should be able to display (for the lazy, this would just be one of the > standard encodings like latin1). The interesting way is to prescan as much > characters as available, and, taking all the characters into account that > are visible on the screen at that moment, it could try to find "empty slots" > in the loaded font that it could load with the glyphs for the characters > that are to be displayed. In other words, the 256 glyphs vga font would be > used as a cache for a full blown unicode console font. You could only > display as much distinct characters at a time, and in some cases it would be > performing badly, but in most usage patterns it should work very well, > certainly good enough for a two-language setup like german-greek, or so. > Most of the font slots are barely used (if you doubt that, cat a binary > file for a change) in the western world.
I think this'd be cool, but the failure (when there's more than 256 characters displayed) would be just too wierd. ... Would it be possible to do a hybrid text/graphical mode, where most characters are drawn using the vga fonts, but any extra characters are drawn manually? Or is that what you meant? > > Call me crazy, but I really like my text mode. It would not be too hard > to implement. And I think it would be plain cool ;) I like text mode too. I've got great plans for it. :) -- Adam Olsen, aka Rhamphoryncus _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
