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
