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



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

Yes, I understod what you meant, and I have made one implementation of it
already. I made it 2-pixels extra one for ascent and one for descent. But
I also made it clip the extra pixels if the text was selected because when
the entry has focus it draws one black line in the white border which then
will touch the inverted (selected) area which wasn't nice.
 
> > 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 with that sulotion is the extra care we have to take in a lot
of widgets.

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

That I suppose is an even worse problem with GtkText. It seems that if
I write an aring, but somehow the top pixel get chopped. But if I move
an other window over half the aring (from buttom of the screen) and then
move it away again the pixel will apear. If I the use backspace to delete
the aring character it will not remove the top pixel.

One way to fix that problem could be to redraw the text that gets removed
in the background color. And then rewrite the characters on top and below
if they got hurt. But I should prefeer to se that there at least where one
extra line for the ascent and that the text was drawn inside a clipping 
area.

> 
> Regards,
>                                         Owen

/Mattias



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]