Re: [gtk-list] Re: Font ascents bug

[Mattias Grönlund <Mattias Gronlund sdf se>]

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

I grabbed XProtocoll/proto.txt and you are right.

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

True, how can someone specify a maximum bounding box that doesn't have
to be the maximum bounding box?!?!

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

I'm just impressed!

> I don't want to really want to globally add extra spacing just to
> accommodate 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.

I don't think that is such a good idea, the problem is that a fast look 
in a Swedish dictionary gave me a couple of hundred words that begins 
with aring, which most of them seems reasonable to start a sentence with. 
One solution to the problem could be to make the workaround in the gdk-
layer, such that it always increases the ascends it receives from X.

The problem is that the same problem exists in GtkText...

As what I can see xterm can handle fonts two pixels higher that the 
given ascent for the font, I guess that's why I have never thought
about this before.

> Regards,
>                                         Owen

/Mattias