Rendering text question (context is MSWin UI Automation)

Boris Borcic bborcic at gmail.com
Thu Jan 25 05:55:54 EST 2007


Chris Mellon wrote:
> On 1/24/07, Boris Borcic <bborcic at gmail.com> wrote:
>> Chris Mellon wrote:
>>> Using either win32 or wxPython you will be able to produce bitmaps
>>> directly, without needing to create a visible window.
>>>
>>>
>>> Some quick & dirty wxPython code
>>>
>>> def getTextBitmap(text, font, fgcolor, bgcolor):
>>>     dc = wx.MemoryDC()
>>>     dc.SetFont(font)
>>>     width, height= dc.GetTextExtent(text)
>>>     bmp = wx.EmptyBitmap(width, height)
>>>     dc.SelectObject(bmp)
>>>     dc.SetBackground(wx.Brush(bgcolor))
>>>     dc.Clear()
>>>     dc.SetTextBackground(bgcolor)
>>>     dc.SetTextForeground(fgcolor)
>>>     dc.DrawText(text, 0, 0)
>>>     dc.SelectObject(wx.NullBitmap)
>>>     return bmp
>>>
>>>
>>> Raw win32 code will look similar but will be much more verbose.
>> Thx again for this base.
>>
>> Quickly testing this, it appears that the result is rendered half a pixel off in
>> the x-direction. Does this make sense ? Is it possible to position text with
>> subpixel accuracy ?
>>
> 
> The GDI text api, which is what wx is wrapping here, only provides
> pixel accuracy. You are probably seeing a kerning effect from your
> chosen font and perhaps the effects of ClearType.

I am not. Turning antialiasing off (as a desktop setting) changes the rendering 
but wx._gdi_ still insists that horizontal coordinates are between pixels (to 
the contrary of vertical coordinates). This means thin black vertical lines are 
rendered by two pixel columns, the left one red, the right one cyan. 
Non-aliased, 90-degree rotated text is still smeared likewise left-to-right on 
the screen what becomes top-to-bottom relative to the text. Setting the scales 
at 0.5 and drawing the text one pixel off (to express a half-pixel shift) 
doesn't work. A long almost vertical thin black line that's one pixel off 
top-to-bottom results in two parallel vertical uniformly colored red and cyan 
pixel columns, broken in the middle.

In short, wx._gdi_ fights quite hard to enforce what I am trying to avoid :( I 
might admire its consistency if it extended to treating both axes similarly...

Regards, Boris Borcic




More information about the Python-list mailing list