Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-1233821

Win32 only: font sizing incorrect (pixels vs points?)



    • Bug
    • Resolution: Duplicate
    • P2
    • None
    • 1.0
    • client-libs
    • x86, sparc
    • solaris_2.4, windows_95


      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:


       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

      cheers, bc


        Issue Links



              gsaab Georges Saab
              duke J. Duke
              0 Vote for this issue
              0 Start watching this issue