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 bu
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
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,
Thank you, I'm still compiling the j2d forest, then I'll push to the
2d-gate.
Thanks,
Mario
--
pgp key: http://subke
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 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 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 :
I've
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 sen
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 interes
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 Mario,
> > What I'd like to have is a small test case that demonstrates exactly
> > this so I can follow the chain.
> I've uploaded a small test case, where only one font is tested, my
> original test case let you select the font from a combo box list with
> all the font installed, but becaus
Il giorno mer, 19/05/2010 alle 14.34 -0700, Phil Race ha scritto:
Hi Phil,
> BTW Its not just ascent and descent, there's problems on the left and
> right sometimes
> as logical left and advance don't necessarily encompass all the pixels.
I noticed this as well, like this screenshot proves:
ht
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 wrongly
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 se
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
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 oper
Too many emails with too many comments for me to address them all.
- 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. Actually
due to some perhaps
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 d
Il giorno mar, 18/05/2010 alle 23.33 +0200, Mario Torre ha scritto:
> 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 +
> > > > > bmodi
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 anothe
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
Il giorno dom, 09/05/2010 alle 14.17 +0200, Mario Torre ha scritto:
> 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 her
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 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 immed
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
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.
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 full
Mario,
If you look around lines 567-573 you'll see a comment to the
effect that it was decresed fom 0.99 to 0.95 because that higher
value was causing problems. This was back in 2001 and all I can
recall from then is that it took a long time to get the right
formula ..
See http://bugs.sun.com/vi
Il giorno lun, 22/03/2010 alle 23.27 +0100, Mario Torre ha scritto:
> I started tracking this because anything I write something with an
> underscore in NetBeans I don't see the underscore, and that drives me
> crazy (ok, it also affect JamaicaVM, but I fixed it because I type my
> code in NetBean
Hi Jim, Roman, Java2D people,
I'm trying to fix an annoying bug that appears almost always fonts are
rendered without antialiasing:
http://www.limasoftware.net/neugens/downloads/stuff/font2dbug/bug.png
I started tracking this because anything I write something with an
underscore in NetBeans I do
29 matches
Mail list logo
