http://bugs.winehq.org/show_bug.cgi?id=30951
--- Comment #1 from Dmitry Timoshkov dmitry@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@baikal.ru Date: Fri May 11 19:19:21 2012 +0900
gdiplus: Retrieve LOGFONT from a GpFont using GdipGetLogFontW instead ofaccessing 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.