[OpenJDK 2D-Dev] Font rendering issue

[Phil Race]

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 that all pixels
> *do* fit into 'height'. This leads to (e.g.) '_' beeing cut off.
>   

What I was saying is that they know problems can arise but its a compromise.
I recall there were attempts in the past to ensure mnemonics were properly
positioned and I would suppose, visible.
You need to use logical metrics, not the glyph's visual bounds to position
an underline otherwise it'll be like a wandering baseline
However you don't know where all the pixels fall from font-wide metrics, 
and glyphs
with diacritics have been known to be placed above the supposed max ascent.

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.

So maybe Swing is culpable here. Its also possible that
something isn't ideal in the delicate task of making choices about how
to round up several inter-related floating point numbers
What I'd like to have is a small test case that demonstrates exactly 
this so I can follow the chain.
Mario sounds to  have  that, right down to specific font and size and 
using the same mnemonic
positioning logic as swing.

>   
>>  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..)
>
>   
Leaving aside for a moment the issue of the rounding problem,
What is "correct"  metrics ?
T2K (the JDK  rasteriser) was from one of the original Apple truetype 
engineers
and Apple have always used the hhea table for ascent, descent, and linegap
and so does T2K

freetype, I don't know for sure sfnt_load_face has several options and
some of them are ifdefed out in the source I have for 2.3.5

The part that's not ifdefed out appear to use the same data as the JDK

        root->ascender  = face->horizontal.Ascender;
        root->descender = face->horizontal.Descender;

        root->height    = (FT_Short)( root->ascender - root->descender +
                                      face->horizontal.Line_Gap );

The ifdefed out code gets it from the OS/2 table's  
typoAscender/typoDescender .
(BTW there's also usWinAscent/usWinDescent. My impression is that 
Windows GDI
has always used the latter, although maybe GDI+ and other APIs use the
former

None of these are wrong. They are just different.
So long as they are internally consistent this is fine.

BTW as MS note you can get clipping with usWin values too ..
http://www.microsoft.com/typography/otspec/os2.htm#wa

Since with T2K we are using data from the hhea, we are essentially getting
max ascent as ascent and max descent as descent.

http://bugs.sun.com/view_bug.do?bug_id=6623223
This is an unfortunate state of affairs but one that's risky to change.
Where I can imagine that this might cause problems is in code that got used
to ascent/descent being "max" values, and it doesn't work so well when they
are not. Perhaps some of the problems in Swing are related to that except
that if freetype is doing this too, I'm not sure we can blame that.


>>   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. 

Is that exactly what you see ?
The final calculation for reporting the integer value for leading is 
actually
            (int)(0.95f  + descent + leading) -  (int)(0.95f  + descent);

I must be missing something I don't see how this could end up negative 
if leading were 0
unscaled or otherwise. What could happen is if  it became a very small 
negative
value, like -0.01, and this coincided with descent with a value like 
3.05, which
would be just enough to make the first expression round down  ..
ie
(int) (0.95 + 3.05 - 0.01) - (int)(0.95+3.05)  => (int)(3.99) - 
(int)(4.00) => 3 - 4 => -1 ..

It looks like freetype and t2k are reading the leading from the same 
field so I
can't see that I can point to a difference there being part of it,
I think I'd need to take a look at exactly what is going on in running 
Mario's  test program.

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

This doesn't seem right. They do need to be scaled to adjust for point size
but font-wide metrics are completely unaffected by hinting.
Hinting is applied to a glyph and so can affect glyph specific values such
as advance, as well as its image, but it has no bearing on font wide 
metrics.



>   
>> 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.
>
>   

-phil.
> /Roman
>
>
>