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<[email protected]> 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!
