[OpenJDK 2D-Dev] Font rendering issue

Mario Torre neugens at limasoftware.net
Wed May 5 22:18:44 UTC 2010

Il giorno mar, 23/03/2010 alle 13.10 -0700, Phil Race ha scritto:
> It could be the hinting that Mario referred to. There are some
> notes (not by me) that the T2K values produced in JDK 1.4 when
> hinting was available were more correct than previously - when
> there was no hinting.
> But Swing wanted values that looked right for some common cases
> and 1.0 was excessive. I really can't remember exactly what
> cases after 9 years. And I don't have the cycles to dig up
> and repeat this now.
> So all I can say is that looking at what freetype's results
> are and adjusting for whether or not its using hinting is
> probably what's needed.
> Perhaps if Swing placed the mnemonics based on the underline
> offset of the font it would be better .. but I think Swing
> may just use the "height" of the font as the height of the
> component and taking into account that underline offset
> would add more runtime work and metrics churn now. And
> of course that offset wasn't available in 1.1 days where
> Swing started out.
> -phil.

Hi Phil!

I'm sorry I disappeared, but my priorities got shifted to something
else :(

Finally, I could work on that a bit today, and I think that my initial
estimation was correct.

I've found some interesting things, but first of all, some little

I wrote a small application that draws a character and the bounding box
on screen, as well as printing the various properties for the font, like
ascent, descent, etc..

Here is a screen shot of the application, on the left OpenJDK, on the
right the closed one (rendering the same font):


When printing the values, the thing that came immediately to my eyes is
that the leading is -1, which as far as I understand is an invalid

Because the leading is calculated based on the values of ascending,
descending and the height, I printed the height of the font and here I
got that there is *always* one pixel less in the height as returned by
OpenJDK compared to the closed JDK.

That is, when a font has height of 14 for OpenJDK, it is 15 for the
closed one, etc...

If we print the unscaled values though, we see that they "match", in
other words, there's something that gets lost when FreeType scales the
values from font coordinates to device coordinates, I believe this is
because the operations are done in fixed point maths.

I don't know if this is a bug in Freetype, but I can fix it at this
point doing the scaling myself.

In the proposed webrev I use FT26Dot6ToFloat in conjunction with
FT_MulFix instead of shifting the bits myself, actually I did this just
because the FT documentation says that FT_MulFix is optimised for 16.16
operations, and our scale factor is indeed expressed in 16.16, but I
don't know how this can be faster than height*scale>>16 :)

In any case, here's the webrev:


I've not yet tested with the latest OpenJDK code, but before I update
the whole world, I would like some feedback.

What do you think? :)

Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas GmbH, Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
Geschäftsführer: Dr. James J. Hunt

pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Please, support open standards: http://endsoftpatents.org/

pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:

More information about the 2d-dev mailing list