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
branden@debian.org | support the government.
http://people.debian.org/~branden/ | -- anonymous
Attachment:
signature.asc
Description: Digital signature