> Not within VGA text modes.
> 2^9 is a hardware restriction based on text framebuffer's data semantic.
Yeap. The pixel size is 16 bits for VGA text hardware mode with the top
7/8 bytes dealing with the attributes of the font. Actually for VGA text
mode hardware you have 4 font planes where each one can store up to
256/512 glyphs. The problem is the hardware only allows one font plane to
displayed at one time :-(
> And I think that 9x16 (this is the largest glyph size usable in VGA text)
> is apparently much less than is needed to read Japan glyphs without risk of eyes.
> Even for 12-year-old Japanese person ;-)
Actually you can go up to 32x32. That is the hardware limitation.
> So, VGA text seems not to be an acceptable solution for East Asia.
Correct. The solution I seen japan using (PC9800) is there own
hardware for text console mode, gdccon. I seen the driver done by Osamu
Tomita. The problem is it require ugly hacks to the console layer so it
never included for 2.5.X.
A proper console system needs to be developed to support this. So
yes proper unicode handling must be done in the kernel. In order to do
this a hardware independent screen buffer must be developed for the VT
layer. At present the screen buffer (screen_buf in struct vc_data) is
indentical to the VGA text hardware mode. What we need to do is develope
a screen buffer mapping that would work for every one.
|
