bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: console plans


From: Anders Jackson
Subject: Re: console plans
Date: 16 Feb 2002 18:45:47 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1

nisse@lysator.liu.se (Niels Möller) writes:

> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> 
> > Esp with the input below, I feel much better about Unicode now (although
> > I would not like to support the whole lot of it right from the
> > start, esp the compose characters A + ["] = Ä and stuff like that).
> 
> Yes, unicode is a lot more complex than one might think before getting
> into the details. In particular combining characters and normalization
> issues.
> 
> For the input part, the complexity hits whatever component it is that
> converts unicode or utf8 to a local charset like latin1 (and given the
> current level of support for utf8 in tools like emacs and TeX, I don't
> think eightbit charsets will be abandoned very soon).

But do you need to get in ALL Unicode characters from the console in
every locale?  I think Unicode for internal representation is a Good
Thing.
 
> For output, it hits the component that converts unicode/utf8 to
> glyphs or glyph indices.
> 
> It would probably simplyfy things if you could get away with requiring
> a normalized encoding with precomposed characters, such that every
> glyph you'd want to display corresponds to a single unicode value. I
> can't say if that's possible, though, I have too little experience
> with non-european scripts.
> 
> If the complexity can be managed, using unicode seems like the right
> way to go. A simpler alternative might be X keysyms, they ought to
> cover all characters available on existing keyboards (although I'm not
> sure about if the set of codes is rich enough also for output. I also
> haven't looked at all into X novelties like xkb).

But using X for telling how to get characters from keyboard scancodes
to Unicode is compatible with using Unicode internaly.  Yes, it will
hit the part that convert to output, but that is the part who knows
how to represent things anyway (if it's possibly at all, in that case,
do some thing propper, like a square or somthing, depending if the
device is an old terminal or more mordern graphical console)

Add composing later.  But don't design it not to be possible to expand
later.  Mayby have a good look at Berlin (or what that object oriented
graphical window system that was suppose to be the new X Window was
called)

/Jackson



reply via email to

[Prev in Thread] Current Thread [Next in Thread]