Well, I think I misunderstood ... -----------
In the first para, I asked whether it was possible to use TrueType in the terminal. If we cannot, then we need to use some hybrid of bitmap fonts and OT fonts, such that, the OT features can be used (atleast the GSUB if nothing else) and the Bitmap features can be used (i.e., using a bitmap instead of outlines). ----------- In the last para, I said that I would try (or rather the Typographer and I could try) the following: 1) Since you are assigning widths to characters, and since each logical cluster would get a width = sum of the widths of the characters in that cluster, ... 2) ... all we need to do is design the font in such a way that, the glyph corresponding to a logical cluster would use as much space as available to it. E.g., kra cluster consists of ka + chandrakkala + ra so, when a software (say ls or cat) outputs a sequence ka + chandrakkala + ra, the kra logical cluster will get widthC = width(ka) + width(chandrakkala) + width(ra) allocated to it. In the font, we make sure that the kra *glyph* which corresponds to the kra *logical cluster* uses as much as possible of widthC. With this, characters have a width specification, and glyphs can be moulded to use as much of the space as possible/necessary as per the widths assigned to each *character*. ---------- I hope I have set things right ? Regards, Rajeev J Sebastian ----- Original Message ---- From: Rich Felker <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, November 6, 2006 10:22:23 PM Subject: Re: Proposed fix for Malayalam (& other Indic?) chars and wcwidth 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/ -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
