Package: unifont Version: 1:5.1.20080914-1.3 Severity: normal Dear Maintainer,
I found this under What's Next at <http://unifoundry.com/unifont.html>: * Make some changes for errors and usage preferences requested since the Unicode 5.1 release. Notably the line drawing set will be half-width instead of full-width (I'll make the current full-width set available as a separate file in case anyone wants it for CJK). This seems to refer to the characters U+2580 through U+259F, which *do* look rather wider than the ones I remember from DOS. And it looks *really* bad in "xterm -fa 'unifont' -fs 15"; just try this in Python: >>> print ''.join(map(unichr,range(0x2580, 0x25A0))) It would probably be a good idea to check *all* the widths against the East_Asian_Width property from <http://www.unicode.org/reports/tr11/>. (Presumably, the only reason it's called "east asian" is because only East Asian character sets (and I really mean character sets here!) and fonts actually have such a concept at this point?) Unfortunately, the Neutral (N) and East Asian Ambiguous (A) values for this property don't actually tell us how wide a character should be. Neutral (N) says *nothing* about the appropriate width; for now, it's probably best to follow Markus Kuhn's free wcwidth() implementation <http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c> and treat everything with this value as narrow; it's kind of important to have the same idea of character width as xterm, ncurses, etc. ... East Asian Ambiguous (A) characters "occur in East Asian legacy character sets as wide characters, but as narrow (i.e., normal-width) characters in non-East Asian usage". In other words, Unicode should probably have made compatability characters for these to preserve width when transcoding ... and according to TR11, still *could*, but probably won't. These characters (including the block mentioned at the top of this report) should indeed be Narrow in the default font; a wide variant is likely unnecessary, though: don't existing CJK fonts already cover the legacy encodings used with the sort of program that would need this quite well already, and with higher quality glyphs, too? (Why would anyone use a "CJK legacy" variant of unifont in preference to a native CJK font, when the program in question is probably using a legacy coding *anyway*?) -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages unifont depends on: ii ttf-unifont 1:5.1.20080914-1.3 ii xfonts-unifont 1:5.1.20080914-1.3 unifont recommends no packages. Versions of packages unifont suggests: ii unifont-bin 1:5.1.20080914-1.3 -- no debconf information -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
