Chris Mellon wrote: > On 1/25/07, Boris Borcic <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
