[OpenJDK 2D-Dev] Font rendering issue

Phil Race philip.race at oracle.com
Tue May 18 23:42:32 UTC 2010

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 questionable choices of the fields in the font
   which should be used AND the way that the height of logical
   fonts is assembled (the maximum leading of all components +
   the maximum descent of all components + the maximum ascent of all 
   its higher than I'd like. Much as I'd love to fix this its going to 
get someone upset,
   so I've steered well clear. This goes all the way back to 1.1

  And I doubt we'll be able to go changing Swing either.

  Irritating as this may, where there are consequences for upstream code
   its not something I'd want to sign off on lightly unless its clearly 
fixing a blatant bug.
  We have less compatibility history to maintain (in the behavioural 
sense) in the freetype code
   so that's easier to change.

  Anything in the shared code, I'd want to actually try out. Any claimed 
  in the closed code, I'd want to track down and see if its actually so and
  what we can/should do about it.

  If I have things right, the most obvious problem Mario saw is a negative
  value for leading. That could be an incorrect interpretation of sign 
Seems like rounding up to get rid of it isn't addressing the real problem


On 5/18/2010 2:39 PM, Mario Torre wrote:
> 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 +
>>>>>>                bmodifier) + ay - dy);
> Just one little note.
> Because this is not necessarily just a rounding problem, but it's an
> hinting problem, it would be possible to construct a case where this fix
> is not enough either.
> I'm not so deep into this code (this area in general) to know by
> intuition if this is the case or not, or if there's an obvious
> alternative, this is another reason I'm pushing a bit for a reply, I
> would like to get some insight from the people who wrote this code in
> the first place ;)
> And yes, I want this fixed in OpenJDK as soon as possible, now that I
> know the cause and a possible solution, editing in NetBeans is starting
> to be so annoying, makes me feel really bad!!!
> Thanks,
> Mario

More information about the 2d-dev mailing list