Re: Font ascents bug

[Owen Taylor <otaylor redhat com>]

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

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

I don't think I was very clear in describing my solution. The Entry
widget has two windows. The outer window includes the shadow surrounding
the entry and two pixels of white border. My idea was to move
the white border into the inner window, so the border did not
clip the font as drawn.

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

This would be a bad idea since we don't want to increase the
spacing for everybody. We just want to not clip the Aring
and let it infringe on the area above.
 
> 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.

I have no idea why this is occuring in GtkText. (Well, I might
understand why that pixel would get clipped off in some circumstances,
but it should be intermittant. If it is continual, that implies that X
is actually clipping the font itself. If X is doing the clipping, than
there isn't much we can do.)

Regards,
                                        Owen