[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

font bug

From: Roland Silver
Subject: font bug
Date: Sat, 14 Oct 2000 10:55:41 -0600

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!

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


--Roland Silver <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]