-
Bug
-
Resolution: Fixed
-
P3
-
1.4.0
-
None
-
beta2
-
sparc
-
solaris_7
In all the Java 2 releases the methods on FontMetrics such as
getAscent(), getDescent(), getLeading() are calculated and storeed as
floating point values but the values returned to the application are
all rounded up to the next integer.
Since the value returned from getHeight() is internally calculated as
getAscent()+ getDescent()+getLeading()
then a actual floating pt ascent of 8.1, leading of 0.5, descent of 3.1 could
becomes a returned height of 14 (9+1+4), rather than its floating point sum of
11.7
At least getHeigth() should sum the floating point values, and also perhaps
we should consider rounding to the nearest integral value for the returned
value of ascent, descent, leading, or at apply some intermediate threshold.
Such a policy should also be considered for getMaxAdvance ()
Implementing these changes would appear to be much more compatible with the
values returned by win32 platform APIs which also report integer values.
getAscent(), getDescent(), getLeading() are calculated and storeed as
floating point values but the values returned to the application are
all rounded up to the next integer.
Since the value returned from getHeight() is internally calculated as
getAscent()+ getDescent()+getLeading()
then a actual floating pt ascent of 8.1, leading of 0.5, descent of 3.1 could
becomes a returned height of 14 (9+1+4), rather than its floating point sum of
11.7
At least getHeigth() should sum the floating point values, and also perhaps
we should consider rounding to the nearest integral value for the returned
value of ascent, descent, leading, or at apply some intermediate threshold.
Such a policy should also be considered for getMaxAdvance ()
Implementing these changes would appear to be much more compatible with the
values returned by win32 platform APIs which also report integer values.
- relates to
-
JDK-4161364 List : size of listbox depends on when pack() is called
-
- Open
-