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