JDK-4759380 : FontMetrics/Font incorrect at high resolutions under Suse Linux 8.0
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt:i18n
  • Affected Version: 1.2.1,1.4.1,1.4.1_01
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2002-10-08
  • Updated: 2002-11-17
  • Resolved: 2002-11-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
1.4.2 mantisFixed
Related Reports
Duplicate :  

Name: jk109818			Date: 10/07/2002

java version "1.4.1"

Can we get this fix as well in 1.4.1_03 ?
SAP needs a relief and they don't want to commit to 1.4.2
in their current release scdeule. We're falling short of a month :-(

Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)

2.4.18 Kernel

XFree86 4.2.0 with NVidia MX440 graphics chip and NVidia driver

It appears that JAVA running under Linux reports incorrect
Font Metrics or should be rendering a larger font for the
requested point size at high screen resolutions.  By high
resolution I mean 1600x1200 although it will proably also do
it at higher than 1600x1200 but cannot test this myself.

This problem is not seen at lower screen resolutions
(1024x768) on a similar Linux system nor is it seen under
Warp 4 running at the same high (1600x1200) resolution.

I have prepared a detailed problem report, sample, and
analysis as an HTML page for clarity that I put on our web
server it can be accessed by visiting the folowing URL:


1. See the sample on the site www.aquilasys.com/fmproblem.html

I would expect the proper font metrics or a larger font to
be rendered that matches the reported font metrics.  I see a
font that is much too small or metrics that are simply wrong
depending on how you look at the problem.

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Source code is at the link www.aquilasys.com/fmproblem.html

---------- END SOURCE ----------
(Review ID: 165463) 
SAP provided as test case including screen shots of the problem:

Problem description

The fonts delivered by SUN as .../jre/lib/fonts/* and used when
employing the standard .../jre/lib/fonts.properties only work with
75dpi resolution when using an X-Server that really relies on the font
height information inside the font as Xfree86 4.2.x does. (c.f. XFree
docs).  Fonts heights reporte are just wrong when display resolution
is greater then 75dpi.

Problem reproduction:


OS      : Linux,
          Linux ls3613 2.4.18-4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686 

Distribution: SuSE 8.0

X11     : Xfree86 4.2.x

          XFree86 Version 4.2.0 / X Window System
          (protocol Version 11, revision 0, vendor release 6600)
          Release Date: 23 January 2002
          If the server is older than 6-12 months, or if your card is
          newer than the above date, look for a newer version before
          reporting problems.  (See http://www.XFree86.Org/)

Java VM : SUN 1.4.1_01

          Java(TM) 2 Runtime Environment, Standard Edition (build 
          Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

boot into console usually runlevel 3 no X.

start a X-server with 106 dpi resolution

startx -- :0 -dpi 106 &

start FontRes.class
java FontRes
(see 75dpi.gif)
start FontTest and see what font height is reported.
java FontTest

switch back to the console

start a X-server with 75 dpi resolution

startx -- :1 -dpi 75 &

start FontRes.class
java FontRes
(see 106dpi.gif)

compare the different font cell heights and the overall appearance.
also have a look in the font heights reported by FontTest.java

###@###.### 2003-04-04

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b08

EVALUATION I was not able to reproduce this bug. I requested more information from the submitter but haven't heard back I will mark this bug incomplete pending more information. ###@###.### 2002-10-10 ============================ I have made some progress on this bug. I located a Suse Linux 8.0 and was able to reproduce it. on this linux version the Type1 font used for the symbol component of all logical fonts has been moved from /usr/share/lib/fonts to /usr/X11R6/lib/X11/fonts/URW which appears to be a symbolic link to /usr/share/ghostscript/fonts Consequently Java 2D can't locate the font file, and backs off to accessing the font only through X11 APIs. The font file itself is identical to that on RedHat 7.2 and the difference is that we are now dependent on X11 to report metrics rather than gathering them ourselves. In which case I can imagine that the Xserver is adjusting the returned metrics based on the Xserver DPI. The large glyph images I see makes me suspect its also doing the same for the images. Java2D when it accesses fonts always uses 72dpi when talking to its scaler. It would require investigation of the behaviour of a lot of Xservers to decide whether we should normalize for this and perhaps the simplest fix is to create a font.properties for Suse Linux which allows us to access the font directly as that is needed in any case in order for 2D APIs to function properly. ###@###.### 2002-11-07 ============================ I've checked the PRD and Suse 7.1 is the latest release supported on JDK1.4.1, so Suse 8 support would be a new requirement. Suse 8 is listed as a supported release for JDk 1.4.2 (aka mantis) so I am marking the bug as commit to fix in 1.4.2 ###@###.### 2002-11-08 ============================ t2k does not work correctly when asked for metrics for "Standard Symbols L", it is hardcoded to use the ascent data of character "M" and descent data of "g" for the ascent/descent/leading metrics for any Type1 fon, but seems like this logic does not work for "standard symbols l". as a solution, we remove the symbols font from suse8.0's font.properties file. ###@###.### 2002-11-14