[OpenJDK 2D-Dev] fixing OpenJDK font rendering

Aekold Helbrass helbrass at gmail.com
Thu Sep 29 19:33:47 UTC 2011

On Thu, Sep 29, 2011 at 9:40 PM, Phil Race <philip.race at oracle.com> wrote:
> On 9/29/2011 11:33 AM, Aekold Helbrass wrote:
>> So... You really mean that swing may not respect desktop font
>> rendering settings and must keep rendering fonts with the same
>> uglyness forever, even in native look and feels? No wonder swing is so
>> dead...
> I don't think you are reading what I wrote. The native GTK  L&F *does* do
> that  ..
> I even pointed you to the source code that handles it.

I am reading, also I checked PangoFonts class. It is just changing
size of font instead of setting up proper freetype rendering. Because
of this freetype first of all will not be able to apply proper
subpixel rendering, because it has to know real number of pixels,
calculated from DPI and pt size of font, not just 72 dpi and increased
size. Second, hinting algorythms of freetype will not work either,
because hinting depends on pixel grid so needs exact pixel sizes too.
Please see screenshot in attachment, showing that even GTK look and
feel rendering is different from real GTK app (gedit in the

> And "size difference" != "ugliness"

With that I can fully agree, but I have few points here too. First of
all, swing fonts are still ugly as you can see on screenshots I've
sent. Also, swing is not respecting desktop properties, so in any
modern linux desktop environment all apps will look similar (they
respect fontconfig settings, written by user himself or distribution
developers) but swing will be different, and not in a good way.

Being fan of netbeans and swing architecture I wanted to see pretty
fonts and to get rid of those "wow your netbeans is ugly, why don't
you switch to eclipse?", and with my dirty hack I almost did, with few
problems when components are requesting fonts with greyscale or mono
rendering. So as you can see I am not very happy that swing is doomed
because it has to render fonts in some strange manner instead of
respecting system and user settings and getting 100% similar glyphs.
It's a pity swing is so powerful and with really great design, but
nothing is written in swing but few developer tools and maybe few
corporate apps based on netbeans platform. And as for me this visual
difference between swing and native apps is not the last reason for

> -phil.
>> On Thu, Sep 29, 2011 at 8:56 PM, Phil Race<philip.race at oracle.com>  wrote:
>>> 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
>>> change.
>>> The GTKLookAndFeel code accounts for the desktop DPI used by the desktop
>>> and scales the font size appropriately.  Take a look at
>>> src/share/classes/com/sun/java/swing/plaf/gtk/PangoFonts.java
>>> In your application, not in JDK code, you could try what it does there
>>> and getDeskProperty("gnome.Xft/DPI"); and scale your font size
>>> appropriately.
>>> -phil.
>>>>> -phil.
>>>>> 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?
>>>>>> Thanx!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot06.png
Type: image/png
Size: 36149 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20110929/a9471810/screenshot06.png>

More information about the 2d-dev mailing list