Re: xterm-153 WIDE_CHARS Xft patch
Hi, At Sun, 1 Apr 2001 16:32:41 -0500 (EST), [EMAIL PROTECTED] wrote: I have noticed one problem with this: characters like U+300A, U+300B and U+201C, U+201D are single column according to my_wcwidth(), but simsun.ttf display them as double column. Especially U+300A and U+201C, when it is displayed, it is overwritten by the character following it. Do you know Robert Brady's patch? The newest version of his patch (http://www.xfree86.org/pipermail/i18n/2001-March/001380.html) has three width modes. Though there three modes are not yet perfect for CJK people, it covers almost cases. (Some imperfectness come from problem of conversion table between Unicode and other encodings.) Robert is one of active developers of XTerm. AFAIK, the doublewidth and combining character support of current XTerm is written by him. I expect his newest patch for locale-sensibility/XIM/language-tag/bidi/etc is also integrated into XTerm sooner or later. Note that the patch is XTerm-152-based. BTW, XTerm has a policy that doublewidth character is supported using another font from normalwidth character. Thus, it does not support, for example, GNU unifont. Though I don't checked your patch yet, your patch seems to be like a support for GNU unifont (if your patch is extended to support not only FreeType but also normal font). I don't know how strong the policy is, because the policy has been already determined when I joined the development of XTerm. IMO, if "common font both for singlewidth and doublewidth" way is proved to be convenient, it may be supported, though it may bring width-conflict problem. - Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/lists/
Re: xterm-153 WIDE_CHARS Xft patch
On Tue, Apr 03, 2001 at 11:34:01AM +0900, Tomohiro KUBOTA wrote: Thus, it does not support, for example, GNU unifont. Though I don't checked your patch yet, your patch seems to be like a support for GNU unifont (if your patch is extended to support not only FreeType but also normal font). It's trivial to split the unifont into single and double width, if so neseccary. I've considered mailing a patch to the Debian unifont maintainer to do so for Debian, and will probably argue for it on [EMAIL PROTECTED] if Roman Cyzzabora ever makes another release. Is there any reason not to split GNU Unifont (at least the bdf version) into single and double width fonts? -- David Starner - [EMAIL PROTECTED] Pointless website: http://dvdeug.dhis.org "I don't care if Bill personally has my name and reads my email and laughs at me. In fact, I'd be rather honored." - Joseph_Greg - Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/lists/
Re: xterm-153 WIDE_CHARS Xft patch
From: David Starner [EMAIL PROTECTED] DS It's trivial to split the unifont into single and double width, DS if so neseccary. I've considered mailing a patch to the Debian DS unifont maintainer to do so for Debian, and will probably argue DS for it on [EMAIL PROTECTED] if Roman Cyzzabora ever DS makes another release. Is there any reason not to split GNU DS Unifont (at least the bdf version) into single and double DS width fonts? But it may not so trivial to split font like truetype, etc. Or even if it is trivial, it may not be desired: I may not want to split a font file just because I have to make it to work with xterm. From: Tomohiro KUBOTA [EMAIL PROTECTED] TK BTW, XTerm has a policy that doublewidth character is supported using TK another font from normalwidth character. Thus, it does not support, TK for example, GNU unifont. Though I don't checked your patch yet, TK your patch seems to be like a support for GNU unifont (if your patch TK is extended to support not only FreeType but also normal font). In terms of Xft support, currently, the font selection is not through -fn -fw but -fa -fs. The changes I made is solely experimenting and I am not aware of any policy regarding double-width character font. I think the problem I am experiencing is related to general proportional font support. Currently, *DrawString() is used in xterm but xterm is really column based application. For proportional font, this could introduce the gap/overlap behavior I have seen. To draw one character at a time will also has this problems, but at least it is in line with the assumption of the column base xterm application and the gap/overlap is per character (which should be smaller) rather than per string (which should be bigger). Regards, - Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/lists/
