6961732: FontMetrics.getLeading() may be negative in freetype-based
OpenJDK builds
-phil.
On 6/16/2010 8:43 AM, Mario Torre wrote:
Il giorno ven, 11/06/2010 alle 09.51 +0200, Mario Torre ha scritto:
Il giorno gio, 10/06/2010 alle 14.28 -0700, Phil Race ha scritto:
I've root-caused
Il giorno mer, 16/06/2010 alle 18.52 +0200, Mario Torre ha scritto:
Il giorno mer, 16/06/2010 alle 09.37 -0700, Phil Race ha scritto:
6961732: FontMetrics.getLeading() may be negative in freetype-based
OpenJDK builds
-phil.
Hi Phil,
I need to fill the reviewer field, what is your
Il giorno mer, 16/06/2010 alle 19.40 +0200, Mario Torre ha scritto:
Il giorno mer, 16/06/2010 alle 18.52 +0200, Mario Torre ha scritto:
Il giorno mer, 16/06/2010 alle 09.37 -0700, Phil Race ha scritto:
6961732: FontMetrics.getLeading() may be negative in freetype-based
OpenJDK builds
I've root-caused this although its still not clear what's the ideal answer,
the simplest and safest may be Mario's proposed fix here from 5/5/2010 :
http://cr.openjdk.java.net/~neugens/100134/webrev.01/
So, yes, I think as Mario suggested it starts with something in
freetype which has a #define
Il giorno gio, 10/06/2010 alle 14.28 -0700, Phil Race ha scritto:
I've root-caused this although its still not clear what's the ideal answer,
the simplest and safest may be Mario's proposed fix here from 5/5/2010 :
Hi Phil!
Thanks for the long explanation, everything makes perfect sense
Il giorno ven, 28/05/2010 alle 20.25 +0200, Mario Torre ha scritto:
Ok, I tried to send once, but the message is moderated as it's too big.
I've uploaded the package here:
http://www.limasoftware.net/neugens/downloads/stuff/font2dbug/FontTest.tar.gz
Hi all,
Is there still any interest in
Il giorno ven, 28/05/2010 alle 19.11 +0200, Roman Kennke ha scritto:
Hi Mario,
You could bundle a specific font with the testcase and use it, so it's
no more system specific.
/Roman
Ok, I tried to send once, but the message is moderated as it's too big.
I've uploaded the package here:
Hi Phil,
- Swing understands that there's no guarantee that all the pixels fit
in the reported height of the line. I don't think you want to space
out the text so much that you guarantee no glyph overlap.
No, that's not really the point. Swing assumes wrongly that all pixels
*do* fit
Il giorno mar, 18/05/2010 alle 15.06 -0700, Jim Graham ha scritto:
The thing that bothers me about this fix is that the value being
returned here is the raw computed value. All of the values in this
routine are being returned in floating point sub-pixel maximum
accuracy. I don't see why
Roman Kennke wrote:
Hi Phil,
- Swing understands that there's no guarantee that all the pixels fit
in the reported height of the line. I don't think you want to space
out the text so much that you guarantee no glyph overlap.
No, that's not really the point. Swing assumes
Hi Mario,
ly = (jfloat) ROUND(FT26Dot6ToFloat(
scalerInfo-face-size-metrics.height +
bmodifier) + ay - dy);
And here is the proposed webrev:
http://cr.openjdk.java.net/~neugens/100134/webrev.02/
As noted, this doesn't really fix all the
Il giorno mar, 18/05/2010 alle 21.07 +0200, Roman Kennke ha scritto:
Hi Mario,
ly = (jfloat) ROUND(FT26Dot6ToFloat(
scalerInfo-face-size-metrics.height +
bmodifier) + ay - dy);
To be honest, I don't like that. It's (yet another) workaround for
The thing that bothers me about this fix is that the value being
returned here is the raw computed value. All of the values in this
routine are being returned in floating point sub-pixel maximum
accuracy. I don't see why *this* code needs to round this value. If
something that uses the data
Phil's message brings up another issue for me with the patch. Why use
ROUND instead of a ceiling operation? Do we know what the best option
is for the code above?
Again, I would strongly favor leaving these base calculations in the
scalar alone and focus more on making sure the proper
Il giorno gio, 06/05/2010 alle 00.18 +0200, Mario Torre ha scritto:
Hi all,
Crossposting, because this is related to what Roman just reported on the
Swing-dev mailing list, the original thread was on 2d-dev with the same
subject as this mail.
When printing the values, the thing that came
Il giorno dom, 09/05/2010 alle 12.14 +0200, Mario Torre ha scritto:
ly = (jfloat) ROUND(FT26Dot6ToFloat(
scalerInfo-face-size-metrics.height +
bmodifier) + ay - dy);
And here is the proposed webrev:
http://cr.openjdk.java.net/~neugens/100134/webrev.02/
As
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
Phil, is it possible that these rounding effects are different in T2K
vs. FT? In this case, the rounding should probably be done in the font
backends altogether. However, I doubt I fully understand what exactly is
going on here. My understanding is that we need to round at least up to
the next
18 matches
Mail list logo
