Re: Why isn't console-cyrillic part of console-data?

[Kenshi Muto <kmuto@debian.org>]

At 26 Jul 04 11:35:32 GMT,
Recai Oktas wrote:
> * Petter Reinholdtsen [2004-07-26 12:49:04+0200]
> > [Recai Oktas]
> > > IMO, the current situation is not wrong, due to its cyrillic
> > > spefisic content it is something that should be maintained
> > > seperately.
> > 
> > I don't understand this argument.  With the same argument, we should
> > have console-latin1, console-ascii, console-big5, and so on and so
> > forth.  
> 
> The situation is not that bad.  There are mainly three types of consoles
> wrt the console handling.  console-tools for "Latin", console-cyrillic
> for "Cyrillic" and the missing one console-jfb for languages with more
> than 512 glyphes.  I think this is a reasonable categorization for
> the things I describe below.
> 
> > And this do not make sense.  The difference is only in the
> > content of some data files, and how these are applied to the linux
> > console.  
> 
> The difference mainly comes from the fact that each of the console
> handling packages mentioned above needs special treatment and we should
> leave this task to the most eligible developer, that is, the one who use
> that type of console in his/her real life.  By this argument, I must say
> that the console-jfb should be maintained by a Japanese developer
> (Kenshi?).  That way, such console problems could be quickly spotted
> and fixed.  I think this fact also ensures the modularization when we
> consider it in d-i.

I may misunderstand your opinion, but jfbterm is completely different
with console-data and console-cyrillic.

- jfbterm is just terminal application as same as bterm.
  It uses framebuffer and is independent of console-*.
  Because this is application,
  - normal-user can't launch up X Window System from here.
  - it can't provide as console by init script.

- console-tools and console-cyrillic can change console characters
  directly. But we, CJK people and people using other multiple byte
  characters can't do such a thing without special patch to Linux kernel.
  There was one patch 'unicon' (by Japanese commercial distributor
  TurboLinux), but this was huge, CJK specific, and finally looks
  unmaintained and removed.

Thanks,
-- 
Kenshi Muto
kmuto@debian.org