Builtin gdiplus behaves as documented but tests are indicating that Windows behaviour sometimes differs from the documentation.
I believe this issue is at least one of the contributing issues to bug https://bugs.winehq.org/show_bug.cgi?id=46947, if not the sole issue. I propose that this flag be disabled until it is well understood. I noticed as issue with DrawString seeming to ignore the flag sometimes(sometimes the text fits without any noticeable defects which I believe is the case with the program in the bug) and sometimes even drawing clipped text with the flag on. Other times it works as expected. I can't seem to find a pattern to identify that could be used to predict its behaviour.
Signed-off-by: David Kahurani k.kahurani@gmail.com
-- v3: gdiplus: Disable StringFormatFlagsLineLimit
From: David Kahurani k.kahurani@gmail.com
Builtin gdiplus behaves as documented but tests are indicating that Windows behaviour sometimes differs from the documentation
Signed-off-by: David Kahurani k.kahurani@gmail.com --- dlls/gdiplus/graphics.c | 5 ++- dlls/gdiplus/tests/stringformat.c | 54 +++++++++++++++++++++++++++++-- 2 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c index 6dc34707bbf..54d92356bda 100644 --- a/dlls/gdiplus/graphics.c +++ b/dlls/gdiplus/graphics.c @@ -5309,7 +5309,10 @@ GpStatus gdip_format_string(HDC hdc, if(height + size.cy > nheight) { if (format->attr & StringFormatFlagsLineLimit) - break; + { + FIXME("Ignoring StringFormatFlagsLineLimit \n"); + } + bounds.Height = nheight - (height + size.cy); } else diff --git a/dlls/gdiplus/tests/stringformat.c b/dlls/gdiplus/tests/stringformat.c index 71fb860e474..62450519759 100644 --- a/dlls/gdiplus/tests/stringformat.c +++ b/dlls/gdiplus/tests/stringformat.c @@ -373,12 +373,26 @@ static void test_getgenericdefault(void) expect(Ok, stat); }
+void set_rect_empty(RectF *rect) +{ + rect->X = 0; + rect->Y = 0; + rect->Width = 0; + rect->Height = 0; +} + static void test_stringformatflags(void) { GpStringFormat *format; GpStatus stat; - - INT flags; + HDC hdc; + GpGraphics *graphics; + LOGFONTA lf; + GpFont *font; + RectF rect, bounds; + REAL height; + const WCHAR *string = L"Hello"; + INT flags, linesfilled;
stat = GdipCreateStringFormat(0, LANG_NEUTRAL, &format); expect(Ok, stat); @@ -430,6 +444,42 @@ static void test_stringformatflags(void) expect(Ok, stat); expect(0xdeadbeef, flags);
+ /* This test illustrates StringFormatFlagsLineLimit behaviour that goes contrary + * to the documentation + */ + hdc = CreateCompatibleDC(0); + GdipCreateFromHDC(hdc, &graphics); + memset(&lf, 0, sizeof(lf)); + + lstrcpyA(lf.lfFaceName, "Tahoma"); + lf.lfHeight = -100; + stat = GdipCreateFontFromLogfontA(hdc, &lf, &font); + expect(Ok, stat); + stat = GdipGetFontHeight(font, graphics, &height); + stat = GdipSetStringFormatFlags(format, StringFormatFlagsLineLimit); + expect(Ok, stat); + stat = GdipGetStringFormatFlags(format, &flags); + expect(Ok, stat); + expect(StringFormatFlagsLineLimit, flags); + /* Get an estimate of line height */ + set_rect_empty(&rect); + set_rect_empty(&bounds); + stat = GdipMeasureString(graphics, string, 5, font, &rect, format, &bounds, NULL, NULL); + expect(Ok, stat); + + /* request to draw in a shallow rectangle with half the line height */ + rect.Height = bounds.Height / 2; + rect.Width = 600; + set_rect_empty(&bounds); + stat = GdipMeasureString(graphics, string, 5, font, &rect, format, &bounds, NULL, &linesfilled); + expect(Ok, stat); + todo_wine + expectf(rect.Height, bounds.Height); + + DeleteObject(hdc); + GdipDeleteGraphics(graphics); + GdipDeleteFont(font); + stat = GdipDeleteStringFormat(format); expect(Ok, stat); }
On Tue Jul 25 15:26:16 2023 +0000, **** wrote:
Marvin replied on the mailing list:
Hi, It looks like your patch introduced the new failures shown below. Please investigate and fix them before resubmitting your patch. If they are not new, fixing them anyway would help a lot. Otherwise please ask for the known failures list to be updated. The tests also ran into some preexisting test failures. If you know how to fix them that would be helpful. See the TestBot job for the details: The full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=135210 Your paranoid android. === w7u_2qxl (32 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w7u_adm (32 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w7u_el (32 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w8 (32 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w8adm (32 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w864 (32 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w1064v1507 (32 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w1064v1809 (32 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w1064_tsign (32 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w10pro64 (32 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w11pro64 (32 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w7pro64 (64 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w864 (64 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w1064v1507 (64 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w1064v1809 (64 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w1064_2qxl (64 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w1064_adm (64 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w1064_tsign (64 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w10pro64 (64 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w10pro64_en_AE_u8 (64 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w10pro64_ar (64 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w10pro64_ja (64 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w10pro64_zh_CN (64 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000 === w11pro64_amd (64 bit report) === gdiplus: stringformat.c:479: Test failed: Expected 00000001, got 00000000
Seems like something must have been fixed in an update or something? The tests definitely run on my Windows 7 virtual machine.
I don't like the idea of going from one wrong behavior to another when it's unclear what other consequences it might have.
Somehow I got the impression that native would always draw at least one line. Are you sure that's not what's happening here?
-
David Kahurani -
David Kahurani (＠kahurani)
-
Esme Povirk (＠madewokherd)