JDK-8111332 : Font spacing is off in textbox control
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: fx2.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2011-02-22
  • Updated: 2015-06-16
  • Resolved: 2011-06-22
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.
Other
fx2.0Resolved
Related Reports
Duplicate :  
JDK-8098116 - Support glyph rasterisation to sub-pixel precision
Description
When typing in a textbox control the character font spacing is off every fourth character.

To reproduce:
Create a textbox control.
Display on your scene.
Use the lowercase character 'e'
Hold down the key to repeat.


Attached is an image of the anomaly. Look at the center of the textbox you'll see the two letters 'e' closer together than the others.
Comments
Reopening the issue as suggested. Feel free to defer.
21-06-2011
As the problem is still there I suggest we defer the issue to the next release instead of closing it. AFAIK that's the right way to deal with the bugs that we can't fix in this release
14-06-2011
You are right. This was supposed to be "won't fix" as it was originally. FX has scalable sub-pixel metrics as an over-riding goal and this is a consequence. Changing this is not what we want to do. The other alternative is to add new support for sub-pixel positioned glyphs which should help perceptually, but that's not for this release. And I'm not sure we'll be able to do that for GDI rendered text.
10-06-2011
The fact that the algorithm choice was not smart enough does not make it 'not a bug' and does not allow anyone say 'that's how it is' The user does not care at all that developers have chosen an algorithm that fails to render simple 'eeeeeeeeeee' string as well as any modern software does. Ability to render 5 symbols in a row as well as any competitor does is a fairly basic requirement, isn't it? I have typed over a hundred symbols now and they all are rendered nice. That's a very basic requirement for text rendering. That's how it should be in FX too. Not 'how it is' now The bug is marked as resolved fixed now. But based on the comments it seems no changes were done. Phil, could you please send a link to code review with the changes or reopen the bug if nothing was really fixed.
10-06-2011
No one asked for you to agree. That's just how it is.
09-06-2011
Can't agree. Even if used rendering algorithm is implemented correctly we observe obvious visible defect.
09-06-2011
I don't see anything I wouldn't expect given that we need to render each glyph at an integral offset and at the same time make the overall advance of the string the scaleable unhinted advance, accumulated with floating point precision. This means every now and again you'll see a correction. A bit like a leap day being added every 4th year. Its not generally apparent unless you display the same character repeatedly. If we let the hardware display the glyph at a non-integral position then the result is appalling on Intel. The longer term solution here is to produce glyphs tuned for sub-pixel positioning which may mask the problem to a degree. But as it stands this is not a bug.
23-02-2011