As already noted by others, this problem is a result of a change in the kernel. That change was reversed in the 2.6.30 kernel. No change should be needed to showconsolefont when running with the corrected kernel. (However, I am not currently a Debian user, so have not tested this. This theory still needs to be tested.)
Here is what was going on: showconsolefont uses a somewhat imaginative method to allow it to work whether or not the console is in UTF-8 mode. It creates its own unimap. Actually, it creates a series of 64-character unimaps as it works (four for 256-character fonts and eight for 512-character fonts). Each of these unimaps uses codes 0x21 through 0x60. (By recycling this same set of codes, it avoids using codes greater than 0x7f and so doesn't need to translate any codes to UTF-8.) It will first map these codes to one set of glyphs, then send the codes 0x21 through 0x60 to the console. Then it remaps those codes to another set of glyphs, and sends them out again. It continues doing this until all glyphs have been displayed. Notice that 0x20 (an ASCII space) is never among the codes mapped. With a good kernel, if if no entry is found in the unimap for a non-ASCII character, the console displays the Unicode replacement character, U+FFFD, and if no entry for that is found either, the console displays a question mark in reverse video. However, if a font doesn't have a unimap, it makes little sense to display all ASCII characters as question marks, so ASCII characters with no entry in the map are passed straight through. So, for instance, character code 0x20 (if not mapped) will display glyph 0x20. Or, in words from the source: /* In legacy mode use the glyph we get by a 1:1 mapping. This would make absolutely no sense with Unicode in mind, but do this for ASCII characters since a font may lack Unicode mapping info and we don't want to end up with having question marks only. */ So, with a good kernel, when showconsolefont sends spaces to separate the columns, all is well: character code 0x20 displays glyph 0x20. However, the change in the kernel (drivers/char/vt.c) mistakenly eliminated this direct mapping. So, the console displays a replacement character. Since the Unicode replacement character, U+FFFD, is not mapped, it falls back on the question mark. What? You see garbage, not question marks? Yes. Each of the unimaps created by showconsolefont maps 0x3f (the ASCII question mark) to a different glyph, none of which happen to be a question mark. Michael, you wondered which kernel introduced this behavior. This problem first appeared with kernel 2.6.28-rc9, 2008-Dec-19 and was released in kernel 2.6.28, 2008-Dec-24. The correction first appeared in kernel 2.6.30-rc3, 2009-Apr-22 and was released in kernel 2.6.30, 2009-Jun-10. Here are the related commits: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.30.y.git;a=commit;h=1c55f18717304100a5f624c923f7cb6511b4116d http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.30.y.git;a=commit;h=c0b7988200a82290287c6f4cd49585007f73175a Norm Pierce -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
