font bug

[Roland Silver]

GNU Emacs 20.5.1 (As supplied by RedHat, unmodified).

Platform: i386 (with Celeron processor chip) + RedHat 6.2 Linux.

Files needed: TrueType font file "modcos.iso.2.ttf" (attached).

Problem: Running Emacs with font modcos.iso.2.ttf, and evaluating the 
ELisp expression (insert-char 160 1) inserts a blank into the current 
buffer, instead of the glyph with code 160, which is a "cents" 
character:

     #
   #####
  #  #  #
  #  #
  #  #  #
   #####
     #

Evidence that it's an Emacs problem, not an XWindow problem: 
Performing (insert-char cc 1), for cc = 32...126 and 161...254 enters 
the other 189 characters of the font into the buffer properly. 
Displaying the entire font with the xfd utility shows all 190 glyphs 
in their proper positions, including the "cents" glyph in position 
hex $A0 = decimal 160.

My two cents: I suspect that Emacs treats character 160 -- which in 
the ISO Latin 1 encoding is called "nbspace" -- non-breaking space -- 
as a space, without consulting the font file to see what its actual 
glyph is.

Maybe this is a feature, not a bug. If so, I think it's a misfeature.

I have an ugly but effective workaround for the time being: I changed 
the font slightly to put the cents glyph in position 255 (which is 
otherwise unused) as well as 160. I can then enter it with 
(insert-char 255 1) and SEE it. Trouble is, the compiler for the 
"Modcap" language, for which this is the font, doesn't know what 
character 255 MEANS, so I had to write an ad-hoc C program which 
takes a Modcap source file and changes all the 255's to 160's. Ugh, 
blech. Talk about the tail wagging the dog!

modcos.iso.2.ttf
Description: Mac BinHex archive

--

--Roland Silver <rollo@kitcarson.net>