At 21 Jan 2005 18:58:41 -0800, Thomas Bushnell BSG wrote: > > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > > Irregardless of what you think about it - the > > western world doesn't need it (where ISO 8859-1 or 15 is enough). > > If only this were true.
Obviously I was exaggerating. > You are certainly right that it's not a Hurd-specific question, and > Debian Hurd should probably just track what other people do, but we > should make sure all our parts do the right thing with UTF-8, and then > be ready to switch when Debian is. I think except for the input method we are completely up to par to an UTF-8 xterm using an 8x13 font on Debian GNU/Linux these days (and even 9x15 if you live with some limitations for extra-wide characters) - and all this in VGA text mode (== fast scrolling) and up to 512 different characters at the same time (if you can live with 8 colors - 256 otherwise). I have carried the VGA text mode to its most extreme, there is little room for improvement in this context (you _could_ do overstrike by handling the font slot allocation even more dynamically, but that's about it). For more, we need to go to graphics mode. For the input method, marco was working on an xkb driver for the console, which means we will support just about exactly the same input methods as X Free 86 (plus/minus the obvious tweaks). You can't get much more complete than that either. UTF-8 is an insanely complex standard, if you start to look down its depths. I am not sure if there is any complete implementation in the world (well, maybe some proprietary solutions for tens of thousands of dollar or so). But we provide the reasonably subset that GNU/Linux also supports. Beyond that you will quickly hit all sorts of limitations, including the fact that the unix console must be mono-spaced(!), while UTF-8 knows something like double-width characters which are twice as broad as normal characters (in mono-spaced fonts). Proper UTF-8 supports carries itself through all layers of the system, from string comparison at the glibc and filesystem level (when are two filenames distinct?) to input and display methods at the application level. It's huge. Heck, we even support _real_ bold and _real_ italic font types on the text console (unfortunately still not yet supported by emacs' font lock mode, although that should be a small hack). And we have a 6x3 cells big GNU Head (see console/motd.UTF-8)! Find that anywhere else in the world :) That said, I have only done little testing with the UTF-8 stuff. I think it is solid, but there may be some error conditions with iconv which mess things up. This will naturally manifest itself once the code gets used a lot. Have fun, Marcus _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
