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.
* On Thu, 25 May 2006, Troy Rollo wrote:
The attached sample program demonstrates a bug in font handling that can lead to corrupted fonts. Compile with "winegcc -g sysfont.c -lgdi32 -lcomdlg32".
I'am running wine from a local src tree, so I had to compile this way:
$ tools/winegcc/winegcc -Btools/winebuild/ -B/usr/bin/ -g sysfont.c -Ldlls -Llibs -Iinclude -mwindows
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,
And in my case it didn't happen.
* On Thu, 25 May 2006, Saulius Krasuckas wrote:
I'am running wine from a local src tree, so I had to compile this way:
$ tools/winegcc/winegcc -Btools/winebuild/ -B/usr/bin/ -g sysfont.c -Ldlls -Llibs -Iinclude -mwindows
Sorry, -B/usr/bin is a leftover from my experiments and isn't needed here at all... I compiled app by running this:
$ tools/winegcc/winegcc -Btools/winebuild/ -g sysfont.c -Ldlls -Llibs -Iinclude -mwindows
BTW, now the issue is seen on my box too. Heh, it reminds my of my own bugreport [*]. Could this be related, Troy?
On Thursday 25 May 2006 20:51, Saulius Krasuckas wrote:
BTW, now the issue is seen on my box too. Heh, it reminds my of my own bugreport [*]. Could this be related, Troy?
No, your problem is definitely different.
On Thu, May 25, 2006 at 04:49:04PM +1000, Troy Rollo wrote:
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.
Nice catch! This should fix it.
Huw.
On Thursday 25 May 2006 19:47, Huw Davies wrote:
Nice catch! This should fix it.
Indeed it does.
-
Huw Davies -
Saulius Krasuckas -
Troy Rollo