Bug 218615

Narrowed down to 'g' 'p' or 'q'

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Created attachment 142955 [details]
testcase

It seems to happen on GtkCheckButton and inherited widgets. however
GtkToggleButton that is parent widget of GtkCheckButton was ok.

Created attachment 142958 [details]
screenshot for example application in fr_FR

String from im-chooser.po

msgid "Use _custom input method"
msgstr "Utiliser une méthode de saisie _personnalisée"

I asssume this happens because we use underline-low for this, and the underline
gets clipped away...

(In reply to comment #5)
> I asssume this happens because we use underline-low for this, and the underline
> gets clipped away...

Correct.

Normally we don't really care if a glyph is clipped (say in a menu name), we
don't want to change the height of the menu bar because of a low glyph.  What we
want however is to make sure the low underline fits in the line boundary
(ascent/descent).  Two solutions pop to mind:

  1. Add a new underline mode.  Ugly.
  2. Make underline-low clip its position to the line descent.  Ugly too.

Should find the lesse or the two evil.  Adding Owen.

Well, underline-low is basically "underline as for menus", so I don't
see 1. as a reasonable choice... if 2. is the correct thing for menus,
then we should just do it for underline-low.

Does this occur for menu items, or just for the menu bar?

Have we considered removing a pixel of padding under menu items, and
then making GtkAccelLabel allocate a pixel more to its child?
(Is there any padding under menu items?)

Sorry, missed that the original example here was a GtkCheckButton, not
a menu item. (I think there is a GTK+ bug open about GtkMenuBar?)

The only thought other than the "squish underline upwards" is to take
advantage of the "draw border" mechanism we have to allow widgets to
draw outside their allocation ...that is, make GtkLabel clip a pixel
bigger on the bottom when there is a mnemonic set, and then stick
a draw border of 1 at the bottom of GtkLabel into the default RC style text 
we parse (currently used for the tooltip background)... a real theme
is unlikely to set a draw border on GtkLabel. Might work, but definitely
hacky!

I can confirm that adding

style "label"
{
  GtkWidget::draw-border = { 0,0,0,1 }
}
class "GtkLabel" style "label"

does indeed seem to fix the issue.

Maybe it would be less hacky to derive the draw-border from the ink rectangle in
gtk_label_size_request (assuming the ink rectangle includes underlines), but
just putting the above hack in the default rc style is probably good enough in
practice.

Fix is in gtk2-2.10.4-9.el5

(In reply to comment #10)

> Maybe it would be less hacky to derive the draw-border from the ink rectangle in
> gtk_label_size_request (assuming the ink rectangle includes underlines), but
> just putting the above hack in the default rc style is probably good enough in
> practice.

The ink rectangle includes the underlines indeed.  Should we move upstream?

I've committed the draw-border hack upstream. If we can come up with something
based on the ink rectangle, we can just replace the hack.

Created attachment 144272 [details]
working fine

it is working fine with following version (check screenshot for details):
gtk2-2.10.4-11.el5

Package is part of following Tree:
RHEL5-Client-20061221.nightly

Reopening since this change uncovers a relatively serious memory leak in  GTK+,
which is a REGRESSION

*** Bug 220580 has been marked as a duplicate of this bug. ***

Memory leak fixed in 2.10.4-14.el5

All supported languages are working normal and shortcut keys are available
 with following version:
gtk2-2.10.4-14.el5

Package is part of following Tree:
RHEL5-Client-20061226.nightly