Path: utzoo!attcan!uunet!midway!linac!uwm.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!SHAMASH.MCRCIM.MCGILL.EDU!mouse
From: mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  font problem (more info)
Message-ID: <9009200941.AA00872@shamash.McRCIM.McGill.EDU>
Date: 20 Sep 90 09:41:51 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 81

> 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