On Sun, Apr 08, 2007 at 08:27:18PM -0400, Thomas Dickey wrote: > grep'ing the code, I see some special case in wcwidth.c (the built-in flavor) > which may be related - makes xterm treat those codes as double-width. I > expect > they're being scaled.
xterm does treat them as double-width in all the default bitmap fonts in the resources; but it's only in 9x15 that the glyph doesn't render, which suggests to me another layer to the problem. > I have a to-do item to make it configurable whether the built-in or system > wcwidth() is used; looks like this case would be interesting to compare. I did not know that character width was determined by codepoint rather than by font-specific information, but if this is something Unicode is standardizing, I think that's a good thing. The code chart for this block of Unicode ("Miscellaneous Technical")[1] seems to suggest that these glyphs should be fullwidth, or at least wide enough to have the angle brackets "hug" the other symbols they enclose, but I find it difficult to argue for the normativity of that observation without more background. [1] http://www.unicode.org/charts/PDF/U2300.pdf -- G. Branden Robinson | If you have the slightest bit of Debian GNU/Linux | intellectual integrity you cannot [EMAIL PROTECTED] | support the government. http://people.debian.org/~branden/ | -- anonymous
signature.asc
Description: Digital signature