Glenn Maynard wrote:

programmers in X care more about X support than Windows
support (which is very annoying to Windows users, who often end up with


old, buggy ports of X software when they get them at all).

off-topic: This is one of many reasons scientific community (astronomy/astrophysics for instance)
was one of the earliest groups that quickly embraced Linux. Their main toolsets
are all written for X11 and their Windows/MacOS ports were buggy and outdated,
but porting them to Linux is a lot easier.


This is actually one advantage of NFD: it makes combining support much
more important. (At least, it's an advantage from this perspective;
those who would have to implement combining who wouldn't otherwise
probably wouldn't see it that way.)


Another advantage of NFD is the consistency. In NFC, some characters
with diacritic marks are represented as precomposed while others are represented
with base character + diacritics. In NFD, all characters are represented the same
way except for some Korean Hangul Jamos due to 'the' very stupid mistake
of South Korean standard body that requsted the removal of decomposition
of cluster Jamos into sequences of simple/basic Jamos. (Overall,
Korean script handling in Unicode/10646 is among the worst.)



By the way, I just gave lv a try: apt-get installed it, used it on a
UTF-8 textfile containing Japanese, and I'm seeing garbage. It looks
like it's stripping off the high bits of each byte and printing it as
ASCII. I had to play around with switches to get it to display; apparently
it ignores the locale. Very poor. Less, on the other hand, displays
it without having to play games. It has some problems with double-width
characters, unfortunately.


Actually, with Owen Talyor's patch posted here about a year and half ago(?), 'less' works
pretty well in UTF-8 under UTF-8 xterm.


Jungshik Shin


-- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/



Reply via email to