Rendering text question (context is MSWin UI Automation)

[Chris Mellon]

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+.