[OpenJDK 2D-Dev] fixing OpenJDK font rendering
philip.race at oracle.com
Thu Sep 29 18:40:00 UTC 2011
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
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.
And "size difference" != "ugliness"
> 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
>>>> 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
>>>> 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