JDK-6587560 : OpenJDK problem handling bitmaps returned when LCD text is requested.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: OpenJDK6,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux_ubuntu
  • CPU: generic,x86
  • Submitted: 2007-07-31
  • Updated: 2011-05-18
  • Resolved: 2011-05-18
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 Other
7 b33Fixed OpenJDK6Fixed
Related Reports
Duplicate :  
Description
In the new OpenJDK b17 usage of freetype, when requesting LCD mode glyphs, if
there are embedded bitmaps, freetype may return those.
Freetype indicates this with as
ftglyph->bitmap.pixel_mode ==  FT_PIXEL_MODE_MONO

This is detected and generally handled correctly.
However when the implementation has already calculated that if it requested
LCD bitmaps, the "width" of the glyph in pixels is 1/3 of ftglyph->bitmap.width.
This doesn't appear to be a valid assumption in the case when an embedded bitmap
is requested.

The "width" problem is for the LCD_HRGB (FT_PIXEL_MODE_LCD) case
A similar problem exists for the LCD_VRGB (FT_PIXEL_MODE_LCD_V) case.

In the width case the glyphs are rendered thin and multi-coloured.
In the height case the glyphs are rendered clipped vertically

For "mono" we should always set
          glyphInfo->width = width; ( == ftglyph->bitmap.width)
          glyphInfo->height = height; ( == ftglyph->bitmap.height)

Comments
EVALUATION Use value of ftglyph->bitmap.pixel_mode to decide whether width/height has to be scaled.
28-05-2008