The attached sample program demonstrates a bug in font handling that can lead to corrupted fonts. Compile with "winegcc -g sysfont.c -lgdi32 -lcomdlg32". Run the resulting a.out, and you will see the letter "C" in the top left corner of the window, rendered in the system font. Click anywhere in the client area of the window and the letter will change its shape, even though it is still using the stock SYSTEM_FONT.
The left click action creates a device context for the default printer and immediately deletes it. As part of the deletion of that device context, DeleteDC selects the stock SYSTEM_FONT into the device context. Since printer device contexts insist on scalable fonts, the existing (bitmapped) GDI font for the system font is unable to serve, so a new one is created, which ends up being based on the Tahoma (TrueType) font. On the next paint loop, when the test program calls SetFont it is the new, scalable font (based on Tahoma) that is found.
The Tahoma font has different glyph codes to the System font, such that 'C' is glyph code 36 in the System font and 38 in Tahoma. Accordingly, x11drv identifies the glyph as not having been uploaded (it has uploaded glyph 36 before), and uploads it as glyph 38 based on its outline in Tahoma.
The problem gets worse later on because some glyphs in the glyphset have been uploaded according to their "System" font positions (or in this case ,the same character has been uploaded in its position in both fonts). Rendering a character that uses the other glyph code results in the wrong character. You can get a mix of Tahoma and System characters appearing on the screen with the System characters displaying the shape of the wrong character.
Every fix I look at seems like a horrible hack. Perhaps find_in_cache should only return bitmap fonts if the device can use them. If the caller then finds there is no bitmap font that matches it can then look for scalable fonts in the cache.