JDK-6989370 : Windows platform fonts may be incorrectly marked as ineligible for the native rasteriser
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2010-10-04
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
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.
JDK 7
7 b128Fixed
Related Reports
Relates :  
JDK-6795908 - Refactor FontManager
Description
JDK uses Windows to rasterise LCD glyphs for Windows installed TrueType fonts
when there is a simple transform on the font.
It uses JDK's rasteriser for all other scenarios (non-LCD, or JRE or
non-installed fonts, rotation transforms etc, or any other platform except Windows).

On creation of the internal font object its marked as to whether its
eligible to be used via the native rasteriser or should always use the
Java one. This is typically based on the location (path name) of the font.

However "6795908: Refactor FontManager" in JDK7 b74 lost this logic
in one place which appears to affect all fonts referenced in the
font config files such that they will always use the Java rasteriser.

However much of this appears to be masked in Font2DTest or other
cases where we locate all the fonts because the fontconfig file
uses upper case names and the registry look up returns lower case
names and we apparently overwrite the first font.

But all of this needs to be fixed.
Comments
EVALUATION The code in Win32FontManger.registerFontFile() needs to check the location of the fonts. Its hardwired default of "true" for useJavaRasterizer is almost always wrong here. In addition the EUDC font probably should be marked with "false", not "true". The map of registerFontFiles should definitely be case-insentive on Windows Need to also check the superclass code for the same logic. Also should Win32FontManager not be in "sun/font" rather than "sun/awt" ? Whilst I can see the bugs in the code I think it will be nigh on impossible to build a regression test for this.
04-10-2010