On Mon, Nov 06, 2006 at 10:14:20AM -0800, rajeev joseph sebastian wrote: > I can say that you have done a good job. My point has so far been > that some kind of special font system should be created. In any > case, the use of straight TTF or OTF is not possible. (is it?). in > that case, it may be worthwhile to investigate a kind of OpenType > Bitmap font :)
It's not a question of the font system not being powerful enough. It's a question of font-specific spacing not being available. It's much more fundamental, the information just isn't there. If I do: cat foo.txt on a terminal, how does the text file query a font and decide how to align itself? It's not a program. Even if it were a program, for example ls, the columnar output would only be correct for one run. If you did: ls -C > listing.txt should ls adapt its output to the current terminal and font it's running on? What if you then do cat listing.txt on a different terminal or with a different font? This is why the notion of column width must be font-independent. If you're talking about making a system where spacing is font-dependent, that's something you can do, but it's a sort of graphic layout language and not a charactercell terminal anymore, and it won't be useful for running any existing terminal apps (their output will corrupt, especially if it causes automargins to wrap in unexpected places) and loses many of the nice properties of a terminal. Note that this is an entirely separate issue from the "excessive spacing" issue. Correction for excessive spacing (with an api more powerful than wcwidth() that takes context into consideration) is one possible design direction for a terminal, but the width would still have to be specified in a font-independent manner. BTW there are also lots of nice things that can be done to get rid of the excessive space "problem", for example pushing all the space forward to the next place where two or more consecutive space, or a tab, or end of line occurs. This can be done entirely at display time so that it does desynchronize with the application's idea of the terminal contents and lead to corruption. The only important thing is to maintain a concept of cells containing characters, without which character-based applications cannot work (and I already explained in the last email why any application running on a terminal must be character-based and not glyph-based). > In this case, since each designer will know exactly how much space > is available, he can *design* conjuncts to fill as much space as > possible. I can talk to the typographer who makes Malayalam fonts > for us on this matter, whether he can think about the problem. Last time I checked even typographers for Latin fonts weren't very fond of character cell terminals... :( Rich -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
