JDK-6282527 : LCD text artifacts due to T2K (font rasteriser) scan conversion of contour to glyph image.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-06-08
  • Updated: 2010-04-04
  • Resolved: 2005-09-06
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 6
6 b51Fixed
Related Reports
Relates :  
Relates :  
Description
Some artifacts can be seen over some letters of some sizes of the Courier New Bold
font, and even a few in Times New Roman Bold when using LCD subpixel text.
The problem is in the T2K rasteriser's scan conversion when presented with
a contour (outline) which has a zero-width part of the contour - essentially a line
sticking out. "y" is one example. where the "**" is a artifact. From a normal
viewing distance it looks like tiny dots or smudges.

    **
 X     X
  X   X
   X X
    X
   X
  X
XX 

The reason is the outline (contour) looks something like this where "++"
are extra lines that extend beyond where they should and its causing pixels
to be turned on that shouldn't be.

 ---------++  ++-------
/         \   /        \
\_____    /   \  ______/
        \   \  /  /
         \   \/  /
          \    /
          /   /
         /   /
        /   /
       /   /
 ----    ---
/           \
\___________/

This isn't a "new bug"  - its been a latent issue in T2K that shows up in
LCD text because it takes a different scan conversion path in T2K.
###@###.### 2005-06-08 17:34:29 GMT

Comments
EVALUATION This problem is specific to implementation of scan conversion for B&W text that is used when we do not hint glyph (e.g. type1 font) or outline is altered after hinting. At the moment we have two different implementations (mostly for historical reasons) and one of them seems clearly obsolete. The proposed fix is to merge them and use more advanced. As side effect of this change we resolve the problem reported in this bug too. Fix for this bug also introduces support for smart dropout control. As results of all these changes some glitches reported in 4924220 are also gone now.
23-08-2005

EVALUATION Subpixel rendering uses alternative implementation of scan conversion (instead of one tightly coupled with hinting engine). This problem is sideeffect of following factors: 1) we shift all coordinates to be odd because current implementation of winding rule assumes this. But on other hand this results in touching extra pixels by hinted ouline 2) glyph in question have rather weird 0 width stems on top that are considered as dropouts by current implementation. These zero width stems are shifted to pixel above glyph and filled due to dropout control logic. Note that this bug was there for long time but it was not noticeable because this implementation of scan convertion logic was mostly used for glyphs we can not hint (e.g. transformed glyphs). ###@###.### 2005-06-23 15:53:26 GMT
23-06-2005