[OpenJDK 2D-Dev] Font rendering issue

[Roman Kennke]

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 into 'height'. This leads to (e.g.) '_' beeing cut off.

>  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 
> components)
>    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

Yeah.

>   We have less compatibility history to maintain (in the behavioural 
> sense) in the freetype code
>    so that's easier to change.

Yeah, but do we really want to bend what freetype reports correctly,
only to make it fit with existing code? I.e. introduce workarounds at
the low level to fix other (multiple levels) of workarounds and bugs at
higher levels? I don't know. I'd rather get text rendering correct even
if it makes somebody upset. (But that's just me..)

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

You can easily try out the reported problems. For example, fire up
Netbeans with OpenJDK on Ubuntu or Fedora, and you'll see that the '_'
is not rendered in many cases, which is *very* irritating because in
code, you really want to see '_'.

>   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 
> somewhere?

I think this comes from height, ascent and descent not beeing
'consistent' in the sense that height-ascent-descent=leading. In this
particular case, ascent+descent is one pixel more than height, and
leading ends up at -1, even though in the font, you have an (unscaled)
leading of 0. This is a problem introduced by the grid fitting, all of
ascent, descent and height are adjusted for grid-fitting, but leading
not (actually, freetype does not report a scaled linegap/leading and we
calculate it from the other 3 values).

> Seems like rounding up to get rid of it isn't addressing the real problem

I believe that we should take the unscaled leading value from the font
and apply the scaling transform ourselves. That's the best that we can
do I think.

/Roman