[OpenJDK 2D-Dev] fixing OpenJDK font rendering
philip.race at oracle.com
Thu Sep 29 17:56:47 UTC 2011
On 9/28/2011 11:10 PM, Aekold Helbrass wrote:
> Hi! Thanx for your answer.
> On Wed, Sep 28, 2011 at 8:50 PM, Phil Race<philip.race at oracle.com> wrote:
>> I can't see exactly what you are proposing since you aren't providing
>> a diff against openjdk master.
> Well, before providing diffs against openjdk master - I want to make
> it as good as possible. So for now those are just experiments with
> what I can and what I can't do.
>> In so far as I could traverse your git repository and find anything
>> I'm concerned by seeing references to "x11Display" in the freetypeScaler.c
>> file which is actually used on Windows too ..
> Exactly. That's why I called it "a dirty hack", "a proof of concept",
> and that's the reason I am asking my questions now - to implement it
> properly. To do that I want to see ideas behind font rendering layer.
> OpenJDK does not belong to me, so I am the one who should be compliant
> with original developer's ideas and styles.
>> And I think you misunderstand how Java defines point sizes.
>> The point size specified to the Font constructor should be scaled
>> from pixels only according to the transform on the Java Graphics2D instance.
>> NOT in response to any desktop DPI setting.
> But freetype2 needs DPI setting to render font properly. That's the
> reason why swing apps are always ugly on linux - swing does not
> respect DPI nor fontconfig proeprties. Every other UI toolkit on linux
> does, including Qt and GTK. And the more DPI screen has - the uglier
> swing looks there. I want to use the same font in kwrite and in
> netbeans, but in kwrite its size 9 and in netbeans I have to set size
> 12-13 to make it the same, but it still looks different. Not to be
> unfounded - please see comparison in attachment, to the left - Qt
> rendering, the same as KDE has, Consolas, from size 16 to size 9 top
> to bottom. To the right - the same but in swing (jdk6u24). And that's
> on the screen with only 96 DPI, on the screens with 130 and more -
> it's even worse. Additionaly, freetype2 has to know exact pixel size,
> calculated from pt size and DPI or set up directly, to render subpixel
> structure properly and make hinter do its job properly. Otherwise
> subpixel structure will be wrong and you'll probably get rendering
> artefacts, plus hinting will be broken.
> Just got another thought... Do you mean that Java have to work that
> way because of backward compatibility or compatibility with
> T2KFontScaler or for any other reason? I mean, that java does not need
> to respect desktop settings but has to work in predefined manner?
I mean that this is how Java is specified. So its not something you can
The GTKLookAndFeel code accounts for the desktop DPI used by the desktop
and scales the font size appropriately. Take a look at
In your application, not in JDK code, you could try what it does there
and getDeskProperty("gnome.Xft/DPI"); and scale your font size
>> On 9/28/2011 6:35 AM, Aekold Helbrass wrote:
>>> Hi All!
>>> I am working on fixing openjdk font rendering on linux (because
>>> currently it's just horrible!), and I've done working
>>> proof-of-concept: https://github.com/Helbrass/openjdk-fontfix
>>> So now I would like to move from dirty workaround to proper clean and
>>> working implementation. And I have some questions about code that
>>> surrounds font rendering and ideas behind that code.
>>> First question is: FreetypeFontScaler.createScalerContext() is not
>>> doing anything, just acting as bridge, and all logic is in
>>> FileFontStrike constructor. And I have to pass DPI to
>>> createScalerContext(). Should I change FileFontStrike and pass DPI to
>>> any scaler implementation or make
>>> FreetypeFontScaler.createScalerContext() read DPI itself because
>>> T2KFontScaler doesn't need DPI or can read it itself?
More information about the 2d-dev