Rendering text question (context is MSWin UI Automation)

Boris Borcic bborcic at gmail.com
Thu Jan 25 13:22:09 EST 2007


Chris Mellon wrote:
> On 1/25/07, Boris Borcic <bborcic at gmail.com> wrote:
>> Chris Mellon wrote:

>>>>>
>>>>> 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 ?
<snip>
>> 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...
>>
> 
> I have not recently had a need to examine drawn text output this
> closely, but I am familiar with the C++ code that implements the
> drawing and it's a direct wrapping of win32 GDI calls. If it's not
> matching your source text, then the source may be drawn using a
> different method or using one of the alternate engines, like GDI+.

Maybe. In any case, color separation solves my (sub)problem : the blue layer 
from the wx generated model matches the green layer from the app's window, pixel 
for pixel (at least with antialiasing and cleartype on, while writing black on 
white).

Best, Boris Borcic





More information about the Python-list mailing list