[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!
modcos.iso.2.ttf
Description: Mac BinHex archive
--
--Roland Silver <rollo@kitcarson.net>
- font bug,
Roland Silver <=