ricks@EE.MsState.Edu (Rick Schumeyer) (09/20/90)
Ok, I guess maybe I should have included some more info on my font
problem. I retrieved a program from comp.sources.x which included a
bdf font, which I ran bdftosnf on. The resulting snf font looks great
on a monochrome SparcStation 1+ (SunOS 4.1, X11R4) when displayed with
xfd. However, it looks real bad when displayed on a color station.
It looks like each character was drawn twice - once correctly and
another time with an x offset of half the character width.
Here is the bdf file, up to the first character's bitmap:
STARTFONT 2.1
FONT demofont
SIZE 64 72 72
FONTBOUNDINGBOX 64 64 0 63
STARTPROPERTIES 3
FONT_ASCENT 0
FONT_DESCENT 64
DEFAULT_CHAR 32
ENDPROPERTIES
CHARS 128
STARTCHAR H00
ENCODING 0
SWIDTH 64 0
DWIDTH 64 0
BBX 64 64 0 -64
BITMAP
{ bitmap deleted }
ENDCHAR
If I run getbdf on the snf file, I get the following messages:
getbdf: no X resolution property found on demofont, assuming 90
getbdf: no Y resolution property found on demofont, assuming 90
I also get this bdf file:
STARTFONT 2.1
COMMENT Generated from X font `demofont' by getbdf
FONT demofont
SIZE 64 90 90
FONTBOUNDINGBOX 64 64 0 -64
STARTPROPERTIES 9
FONT_ASCENT 0
FONT_DESCENT 64
DEFAULT_CHAR 32
FONT "demofont"
POINT_SIZE 640
WEIGHT 117
RESOLUTION 99
X_HEIGHT 0
QUAD_WIDTH 64
ENDPROPERTIES
CHARS 128
STARTCHAR 0
ENCODING 0
SWIDTH 800 0
DWIDTH 64 0
BBX 64 64 0 -64
BITMAP
{ bitmap deleted }
ENDCHAR
The returned bitmaps are correct. The differences appear to be in
SIZE, FONTBOUNDINGBOX and SWIDTH.
Any suggestions as to why this won't display correctly on a color
station would be greatly appreciated.
Rick Schumeyer
ricks@ee.msstate.edu
Drawer EE, Mississippi State, MS, 39762. (601)325-3660mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (09/20/90)
> I retrieved a program from comp.sources.x which included a bdf font, > which I ran bdftosnf on. The resulting snf font looks great on a > monochrome SparcStation 1+ (SunOS 4.1, X11R4) when displayed with > xfd. However, it looks real bad when displayed on a color station. > It looks like each character was drawn twice - once correctly and > another time with an x offset of half the character width. I have trouble seeing how this could be anything but a server bug. (I suppose xfd *could* be responsible, but it seems highly implausible.) What sort of machine is the color station? If it's not a SS 1+, did you copy over the .snf file or did you run bdftosnf on the color machine? (If the former, you might want to try the latter.) > Here is the bdf file, up to the first character's bitmap: [edited down -dM] > SIZE 64 72 72 > FONTBOUNDINGBOX 64 64 0 63 > SWIDTH 64 0 > If I run getbdf on the snf file[%], I get the following messages: > getbdf: no X resolution property found on demofont, assuming 90 > getbdf: no Y resolution property found on demofont, assuming 90 What this means is that getbdf sees no description of the intended X resolution of the font, so it assumes it's supposed to match the screen, and your server claims a 90 dpi screen. I don't know why the resolution values on the SIZE line didn't get turned into resolution properties of the font by bdftosnf. In the absence of explicit resolution properties, I would certainly expect them to. [%] sic. The snf file enters into a getbdf run only incidentally. > I also get this bdf file: [again, edited down -dM] > SIZE 64 90 90 > FONTBOUNDINGBOX 64 64 0 -64 > SWIDTH 800 0 > The returned bitmaps are correct. The differences appear to be in > SIZE, FONTBOUNDINGBOX and SWIDTH. The SIZE difference is easily explained; getbdf had no other values to put there, so it used the screen's resolution. The original .bdf file's FONTBOUNDINGBOX is clearly completely off the wall. If the 63 at the end were -63 it might look sort of plausible, but as it stands it is nonsense. The description of FONTBOUNDINGBOX in the BDF document could easily lead to negating this number by mistake, but the example later on (which is referred to in the FONTBOUNDINGBOX description) makes it clear. Similarly, the original SWIDTH line is simply wrong. (Or perhaps the DWIDTH line is wrong; the two definitely do not agree.) Excerpting from the BDF document: - The word SWIDTH followed by the scalable width in x and y of character. [...] To convert the scalable width to the width in device pixels, multiply SWIDTH times p/1000 times r/72 where r is the device resolution in pixels per inch. The result is a real number giving the ideal print width in device pixels. The actual device width must of course be an integral number of device pixels and is given in the next entry. (The "next entry" describes the DWIDTH line, saying that the first number is the width in device pixels.) Doing this calculation with p=64 (from the SIZE line, or the POINT_SIZE property) and r=90 (from the SIZE line), starting with 800 (getbdf's output SWIDTH value) does produce 64 (the DWIDTH value).... So I would say that the original .bdf file is not consistent with itself. This may have caused bdftosnf to produce a .snf file that in turn confuses the server; it might be interesting to take getbdf's output, bdftosnf it, and try using that. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu