[EMAIL PROTECTED] (Tomohiro KUBOTA) wrote on 29.09.02 in <[EMAIL PROTECTED]>:
> At 29 Sep 2002 08:51:55 +0200, > Eric Streit wrote: > > > > It is probably safe to assume that anybody who wants to avoid > > > framebuffers will not need UTF-8 support, though, so a config option for > > > a stripped down console that way might be useful. > > > > > > > > > if we implement a complete graphical environment in the framebuffer... > > it's a way to reinvent X11 ;) Who wants a "complete graphical environment"? We're just talking about text here. > For example, 18x18ja.bdf in XFree86's CVS today is just about 4MB and > about 600kB when compressed. When we know that this font (or similar > one, which will be in similar size) is mandatory for CJK people, I > imagine nobody would think this size is too large to be included in > Linux source code. What for? What I'd really like to have is to have the *option* (which would presumably be used in the boot scripts by a desktop machine) to download a full Unicode font into the kernel. I can afford 4 or 8 MB unswappable memory in a machine with 1 GB RAM. Hey, I could afford 50. And if someone doesn't need this, such as on a typical server, or in embedded space, or whatever, they'd just not do that. No need to have the font (or the download utility) in the Kernel *sources*, or even to link it in. That probably should imply that the internally kept text screen should have 21 bits for the character value. Given that today we have (I believe) 8 bit for character attributes (colour, blink), if we put both in one 32 bit word (though that is certainly not critical), we'd still have 3 bits left - we could even implement a larger attribute space! (Though maybe some additional trickery for composing characters should be done.) Probably need some corresponding changes for the /dev/v* devices. But leave that until after the tet buffer design is clear. MfG Kai -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
