Re: Font ascents bug

[Owen Taylor <otaylor redhat com>]

Mattias "Grönlund" <Mattias.Gronlund@sdf.se> writes:

> Hi,
> 
> I'm afraid that I have found a bug in the usage of GtkFont->ascent. The
> problem is that the height of a font is ascent + descent + 1 and not
> just ascent + descent, as it is used in app places of Gtk that I have
> checked. 
> If I understands it right, the ascent is pixels high over the main-line
> of the font and descent is pixels deep below the main-line. So that
> give the extra + 1 for the main-line.
>
> You kan see the bug in action by typing an 'Å' (uppercase aring) and a
> 'g' in testgtk:s entry-box. You will see that the g is displayed as it
> should, but the 'Å' has lost one pixel at the top.

At least according to the documentation I have, the baseline does 
not count as a line. 

I think what you are being caught by is that fonts in X don't always
report metrics that correspond exactly to the way they actually draw
themselves. Uppercase Aring is a ridiculously tall character (;-) and
perhaps the font designer didn't want to add an extra pixel of
padding all over the place just for this one character.

(A little poking around reveals that in fact in Adobe Times/Helvetica
12pt, the ascent of the font is 11, but the ascent of the Aring, 12.)
 
> To fix the problem the requsition->height has to be increased and the
> calculation of the main-line (the y-croodinate to gdk_draw_text) has
> to be increased by one.
> 
> At the end of the mail you will find a patch for gtkentry.c to fix the
> problem, but it is just to show what I mean.

I don't want to really want to globally add extra spacing just to
accomodate one character in a few fonts. However, the situation,
I think is still rectifiable. Currently, the entry widget leaves
a two pixel white border around the text area. If this was reduced
to one pixel at the top and the text window was made one pixel
taller, nobody would notice.

Regards,
                                        Owen