> Alex Belits <abelits@phobos.illtel.denver.co.us> writes:
> > > instead. [In forum we additionaly try to approximate chars like 1/2
> > > with string "1/2".] It's doable and I'm doing that in forum. :-)
> >
> > Now imagine what will happen to vi (or anything with curses), if it will
> > think that console uses single character for single character that it
> > displays. This is really a situation where with all "we have unicode on
> > console" talk one can better accept the limitation of hardware rather than
>
> For applications which need fixed-width one-byte display, there obviously
> will not be a multibyte approximation (which is language-dependent anyway).
There will be _something_, multibyte or not, that will be seen on the
terminal. Even if terminal has no slightest idea, what the sequence means,
and displays multibyte as sequence of single-byte characters, or just
wrong characters, two different sequences will look like different ones,
and two equal sequences will look the same. Losing that will only cause
only more trouble.
> > stuff unicode conversion tables into kernel in a poor attempt to cover
> > those limitations up. At least with "dumb" console I can load my charset
>
> You need to stuff _some_ tabels into the kernel,
Why kernel?
> whether they're Unicode or
> whatever doesn't matter much.
It does -- Unicode has no distinction between languages, and requires
translation tables if used with charsets. Charset labeling allows placing
language names with charset, and needs no translation anywhere -- charset
name corresponds directly to actual tables/fonts.
> But since Unicode is the most general way to
> do this we have yet invented,
No, MIME and X internationalization are -- both multiple-charset-based.
> we do it that way until some better universal
> standard comes along.
>
> Fair enough?
"There is nothing more stable than temporary solutions". Once the
language information will be declared useless in multilingual documents,
there will be no way to place it back, and once mapping tables will get
into drivers (or even libraries), there will be no way to get rid of them.
-- Alex
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu