On 29 Jun 2001, H. Peter Anvin wrote:
> By author: Tomohiro KUBOTA <[EMAIL PROTECTED]>
> > or later), "kon" does not (and works with older Linux kernel).
> > [According to the changelog file of "kon", the first test
> > release was 1992-10-13, obviously when framebuffer was not
> > available.]
Just FYI, 'HAN' (and 'HAN2') was patterned after 'KON' and has been
used by Korean Linux users.
> > However, I don't know whether Unicode can be implemented
> > without framebuffer. Just an information.
> Sure it can. The standard console does, and you could do it on top of
> libvga, or whatever. It's just a matter on what level of support.
I agree. I don't see no reason why Unicode can't be done this way.
> Building on top of the framebuffer driver is probably a good idea. It
> still puts the glyphs and terminal emulation code in user space, which
> is probably the Right Thing<TM> to do, especially considering CJK
> (extrememly large glyph set), Indic and Arabic scripts (complex
> shaping rules), as well as combining characters etc.
Actually, HAN (Korean incarnation of 'KON') does NOT use fonts
with thousands of glyphs but uses much smaller fonts with at most a few
hundred glyphs(it can be just tens of glyphs if required) How? HAN (like
'Hanterm', Korean xterm does and support of Indic/Thai scripts need
to do) makes use of 'on-the-fly' generation of glyphs (with component
glyphs). So, in this respect, Korean support should be put along with
Indic/Thai/Arabic (rather than along with Chinese and Japanese).
Jungshik Shin
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
