On Thu, 15 Nov 2001, Tomohiro KUBOTA wrote: > I'd like to know XTerm's policy.
Please read: http://www.cl.cam.ac.uk/~mgk25/unicode.html#xterm > What is the reason of the (un)support of biwidth fonts like GNU Unifont > and /efont/ ? > Is it a policy of XTerm? Or, they will be supported in future? > Otherwise, willing to accept patches to support them? The idea is that xterm decides itself, which characters are single-width and which are double-width and that different width-schemes can be supported using the same font pair. This is obviously not possible by using a single font. Splitting up single-width and double-width characters into two separate fonts has been well-established practice under X11 for a long time and it has worked well. I consider biwidth fonts mostly a product of their creator's unawareness of common practice. I understand that the efont bdf files are already available as separate single-width and double-width charcell fonts and that only the font names (XLFDs) might need minor tweaking such that xterm will find the double-width font automatically. > I have no strong opinion on how biwidth (or doublewidth) fonts > should be assembled. XFree86's doublewidth fonts don't contain > singlewidth glyphs and they are exactly fixed width, while GNU > Unifont and /efont/ contain both singlewidth and doublewidth > glyphs. I don't know which is better. I even have no idea > whether they should follow one united policy or not. I understand that Unifont is probabaly going to be split up into a single-width and a double-width font as well, and I recommend the efont team to do the same. > However, it will benefit users if XTerm will support GNU Unifont > and /efont/ as is. Unifont as is is a HEX format not supported by X11, and some of the conversion to BDF tools split it already in a way suitable for exterm. So "Unifont as is" is perfectly suitable for xterm, unless you use the broken Perl script on Roman's web site. > If a patch with tens of lines for XTerm can > save time of millions of users, it is absolutely worth doing. No. Please spend your enthusiasm on more worthwile goals than this one. The fonts are far easier to fix and your patch would reduce functionality for Japanese users, as it would make locale-dependent font-invariant width selection impossible, something that we want to preserve *specifically* for kterm backwards compatibility for Japanese users who might want to have their beloved double-width cyrillic preserved. Your patch hack would destroy this for no good reason!!! See also http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c for two examples of wcwidth() policies that the same charcell font pair can support efficiently with the current approach. I'm happy to work with both the unifont and efont people to make sure that thier out-of-the-box product is well suited for xterm (and similarly emacs-unicode) and remains a charcell font. Markus -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
