Rendering text question (context is MSWin UI Automation)
arkanes at gmail.com
Thu Jan 25 15:09:06 CET 2007
On 1/25/07, Boris Borcic <bborcic at gmail.com> wrote:
> 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...
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+.
More information about the Python-list