http://bugs.winehq.org/show_bug.cgi?id=30951 --- Comment #1 from Dmitry Timoshkov <dmitry(a)baikal.ru> 2012-06-20 04:43:49 CDT --- (In reply to comment #0)
Bisecting gave me this:
2c93bf7e4e469b36d3244f5a5f3c3c0ca0e0d897 is the first bad commit commit 2c93bf7e4e469b36d3244f5a5f3c3c0ca0e0d897 Author: Dmitry Timoshkov <dmitry(a)baikal.ru> Date: Fri May 11 19:19:21 2012 +0900
gdiplus: Retrieve LOGFONT from a GpFont using GdipGetLogFontW instead of accessing it directly.
This is probably wrong commit. The problem with above commit is - hfont = CreateFontIndirectW(&font->lfw); + status = GdipGetLogFontW((GpFont *)font, NULL, &lfw); + if (status != Ok) return status; + hfont = CreateFontIndirectW(&lfw); which passed NULL graphics to GdipGetLogFontW, which was fixed in a later patch.
It seems it's valid to call GdipAddPathString with a negative font size. This fails now because GdipCreateFont doesn't accept a negative font size, but I don't know if it's correct for GdipAddPathString to call GdipCreateFont.
I've added a test which shows that GdipCreateFont is supposed to fail for a negative emSize. The check in GdipCreateFont was added in the commit c626528a91505292487a4a3b72721122dd68f951 The problem is not in the patch which makes GdipCreateFont fail, but in GdipAddPathString implementation. I'd say that technically it's not a regression, GdipAddPathString was broken before my changes. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.