Re: [Linux-fbdev-devel] The future of framebuffer

[James S. <jsi...@tr...>]

> > > Is this console program or kernel issue?
> > > fbcon is ready for single byte characters, and
> > > jfbterm is ready for more complex language like UTF, EUC, ISO-2022.
> > > Also console-tools is becoming ready for single byte characters and
> > > UTF-8. But I've never seen multibyte characters with default
> > > terminal (with console-tools).
> > > 
> > > -- gotom
> > > 
> > As I see NLS depends on drivers/video/font_8x??.c which were generated by cpi2font.
> > Curently Linux has only english version of these files.
> 
> Right. Currently there is only ISO-8859-1 characters.
> Is it useful to add more characters for ISO-8859-x or
> KOI-8 people ?
> I'm interesting, but I don't know whether there are some demands or not.
> 
> But, adding more complex characters like EUC and ISO-2022
> is more difficult, because they are multibyte characters.
> Handling them is some more hack.
> Their character file is very big because their font have
> more than 30000. Full or partial UTF-8 support invites
> this problem. These days linux has large nls file in fs/nls,
> so I think it's ok, but someone complain about this issue...

The linux console is based VGA text hardware which can only do 8 bit fonts
and only display at most 512 different fonts. So the very backbone of the
console system is limited. I like to see this expanded for 2.5.X. The
framebuffer system could handle it very nicely. Just systems like MDA and
VGA couldn't. Now I don't advocate placing 10,000 characters in the
kernel. I do support have support for them and then having userland tools
that can load such font sets for use.