[python-win32] Fonts behaving differently - The plot thickens a bit

[Roger Upole]

Mark Hammond wrote:

news:4D731EC1.4060902 at gmail.com...
> On 6/03/2011 3:07 PM, Greg Ewing wrote:
>> I think I've narrowed down what's going on with the font
>> sizes a bit more. It has to do with the interperetation
>> of the nHeight parameter to CreateFont.
>>
>> It appears that you can specify the height using either
>> a positive or negative number. One is taken to include
>> the font's internal leading, and the other isn't.
>>
>> What seems to have happened is that somewhere between
>> builds 212 and 216 of pywin32, the behaviour of these
>> two cases has *swapped over*.
>>
>> In my 2.x installation, which is using either 212 or
>> 213 (I'm not exactly sure which at the moment) if I
>> ask for "Tahoma" with height +11 it comes out with
>> ascent = 11, descent = 2; whereas height -11 gives
>> ascent = 9, descent = 2.
>>
>> But under 3.x with build 216, it's the other way around:
>> height +11 gives ascent = 9, -11 gives ascent = 11.
>>
>> If I'm interpreting the MS docs correctly, then the new
>> behaviour is correct and the old one is wrong. Was there
>> a bug relating to this fixed at some point?
>
> Not that I can find - I guess you mean in win32gui?  win32gui has not
> changed since build 214, and the log shows nothing related back to 212.

The conversion in win32ui has changed since 212.  At one time it
was negating the height that was passed in:

if (PyInt_Check (v))
    pLF->lfHeight = -PyInt_AsLong(v);

I looked at it 2 or 3 times before I noticed the minus sign.

>> Also, is there a version number somewhere in pywin32 that
>> I can check at run time to work around this?
>
> There is only pywin32.version.txt installed into site-packages - you
> should look for the value before the first dot without assuming how many
> dots follow...
>
> Mark

You can also extract the version embedded in the pyd's using
win32api.GetFileVersionInfo.

        Roger