There's two public API changes in here and you can get away without
either of them.
So I believe you wouldn't need the changes in SunFontManager,
FontUIResource, or Font.java
Eg in PangoFonts you can write something like :
Font f = new Font(family, style, ((int)dsize+0.5));
f = f.deriveFont((float)dsize); // already public API
FontUIResource fuir = new FontUIResource(f); // already public API
And something similar would need to be done in FontUtilities
The two extra font objects that are created really will not matter as a Font
is a small object and its lazily mapped to a real font.
-phil.
On 8/5/2010 2:20 PM, Omair Majid wrote:
Hi,
A while ago a user pointed out the issue that font sizes between GTK
programs and Swing programs using the GTKLookAndFeel can be
inconsistent. Digging through the code, here is a comment I found in
com.sun.java.swing.plaf.gtk.PangoFonts:
[snip]
* Finally this DPI is used to calculate the nearest Java 2D font
* 72 dpi font size.
* There are cases in which JDK behaviour may not exactly mimic
* GTK native app behaviour :
[snip]
* 3) Because of rounding errors sizes may differ very slightly
* between JDK and GTK. To fix that would at the very least require
* Swing to specify floating pt font sizes.
* Eg "10 pts" for GTK at 96 dpi to get the same size at Java 2D's
* 72 dpi you'd need to specify exactly 13.33.
[snip]
As it turns out, Swing is fine with floating point font sizes: I can
use affine transforms to scale the font. I also noticed that the Font
class supports setting floating point font sizes (through a private
constructor). I have created a patch that makes PangoFont avoid
converting the size to integer units. The webrev is available at:
http://cr.openjdk.java.net/~omajid/webrevs/gtk-floating-point-font-size-support/webrev.00/
Any comments and ideas are appreciated.
Thanks,
Omair