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/
