For Tk problems, it's often useful to know the platform and the Tk version that you're using. I know, for example, that the height of Buttons in Windows was noticable different than in Unix -- or at least it used to be. It had to do with how the y padding was done. On my Windows machine I ran a simple test script, and the Buttons were shorter than I recall which means that maybe something was done to fix this problem in recent versions.

I used to work around this by rolling my own Button by subclassing Label and adding minimal Button-like bindings. This was one of the reasons why I chose to do this for JComboBox, as an example.

GeometryRequest can be fiddly and I have a hard time recommending it, When you use it, you start to contradict what the geometry manager wants to do, and often you end up with a tug-of-war over control of the layout where a widget changes size in odd ways. I would also suggest that by setting a hard-coded value for the height of the Button, then you are potentially putting yourself at odds with whatever the user has designated as the desired height. If you force it to be shorter than the font, then some portion of the text will be clipped.

As Zentara pointed out, the height of a Button or Label is determined primary by the font, but other factors contribute such as:

• the -pady setting (pixels above and below the text)
• -borderwidth setting
• -highlightthickness setting

Of these, typically the one that's causing the problem is the -pady setting. (In the other post, I provided one way of setting this for all the Headers).

Another approach that can be used to constrain the height of a Button would be pack it inside a Frame, then disable pack propagation on that Frame. Now you can control the size of the Button through it's container, and specify a pixel value. As I mentioned before, this is generally *not* a good thing because you want the Button to be at least as tall as the font.