The net of this is that we seem to select font size by confusing units
of pixel height vs point size under win32. If one assumes a display to be
~75dpi, that's not a bad approximation, but otherwise it can be pretty
far off. --bruce




From ###@###.###:

...this is the 'suggested' correct way to compute font size for
given screen for pointsize (from Windows SDK)

  sscanf((LPCTSTR)m_Pointsize, "%d", &size);
  logfont.lfHeight = -MulDiv(size, pDC->GetDeviceCaps(LOGPIXELSY), 72);


Where m_Pointsize is like 10 and converted for the particular system. Here
is the java/C code... which looks suspect to me...


java\\javasrc\\src\\win32\\sun\\awt_font.cpp does:

pFont = Create(PINameToPSName(buffer), pClass->style, pClass->size);

and then inside Create we have:

// Get point size
logFont.lfHeight = -nHeight;


I don't see any computation for screen resolution. From the SDK
documentation for creating a logical font I see:

 lfHeight

 Specifies the height, in logical units, of the font. The font height can be
specified in one of three ways. If lfHeight is greater than zero, it is
transformed into device units and matched against the cell height of the
available fonts. If it is zero, a reasonable default size is used. If it is
less than zero, it is transformed into device units and the absolute value
is matched against the character height of the available fonts. For all
height comparisons, the font mapper looks for the largest font that does
not exceed the requested size; if there is no such font, it looks for the
smallest font available. This mapping occurs when the font is actually used
for the first time.


This seems like the wrong way to do font sizing since the API doc says font
size is in points not aproximated device units.

Anyway, that's what we get by looking quickly thru the JDK beta 1 sources.

Any help we can get would be great!

The description field as copied from bug report 1233736 follows:

From ###@###.### Tue Jan 9 13:40:15 1996
To: avh@Eng
From: BC Krishna <###@###.###>
Subject: Fonts in JDK
Cc: ###@###.###, ###@###.###


Hi Arthur,

I don't know how to say this other than to get on my knees and plead. We've
tried every other avenue without success.

As you know, in the JDK Beta 2.0, there are two bugs in the font code that:
i) prevents applets for using any fonts other than TimesRoman, Courier,
Helvetica, DingBats, and Dialog*, ii) draws the characters at the wrong
size. Both of these we have noticed in Windows 95/NT.

For our product it is critical that applets be able to use any installed
fonts. Bruce Walker in the Java Products Business Group suggests that the
JDK is going to FCS next week. Do you know if the font bug has been fixed in
the FCS? If so, would it be possible for us to get a pre-release copy of the
FCS so that we can test the functionality (for you)? We really consider this
a showstopper in the JDK.

In addition there is another bug in the image code that we also consider a
showstopper. I have reported it as a bug, but here it is:

In trying to implement transparent objects, we enountered the following bugs
in JDK Beta 2.0

    - PixelGrabber hangs occasionally
    - IndexColorMap has a bug in it. Try the following experiment: create
      an offscreen image, draw a white (255, 255, 255) rectangle into it.
      Then use PixelGrabber to get its pixels: they'll all be blue. Similarly,
      red pixels (255, 0, 0) have a similar problem (I don't remember the
      new color)
    - PixelGrabber does not work for framebuffers > 8-bit wide. Get mostly
      black pixels, occasionally, random colored pixels

The above means that we cannot i) use AlphaFiltering, ii) implement our own
transparency.

cheers, bc