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 background. 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): http://www.limasoftware.net/neugens/downloads/stuff/font2dbug/bounds_jdk.png 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 value. 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: http://cr.openjdk.java.net/~neugens/100134/webrev.01/ 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? :) Cheers, Mario -- 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: http://endsoftpatents.org/
