> > > It's also easier to deal with fixed-width fonts than with many typing > > > fanciness, > > > as it is easier to take types as fixed drawings than combine them as in > > > arabic. > > > > both of these problems are quite easy to solve, since they > > can be solved once, and are solved problems in plan 9. > > But then comes the antialiasing, the subpixel rendering for LCDs, the hinting, > and all becomes quite complex. I think plan9 works mostly with bitmap fonts, > isn't it?
plan 9 uses bitmap fonts, but bitmap fonts may be subpixel fonts. i'm using one right now. i think you just made a slipperly slope argument. just because you solve one problem, doesn't mean you have to solve every related problem. > I was not aware that plan9 had the arabic linking solved. Good to know! sorry. i didn't read carefully enough. that's not solved. however, there are some i18n-related problems that are simply solved. my system has 32-bit runes and full unicode 6.0 tables for things like isupperrune, etc. all programs are now happy with runes values up to 0x10FFFF. grep also accepts -I, which by analogy to -i strips everything down to a base rune, like dict(1) has traditionally done. russ has pointed out that converting to character classes would be faster, and it is, but only by about 30%. the first order problem right now is variable-height lines of text so, e.g., Ñ doesn't look so bad. - erik http://www.quanstro.net/magic/man2html/1/grep http://www.quanstro.net/magic/man2html/2/isalpharune http://www.quanstro.net/magic/man2html/2/runeclass
