[PATCH 8/9] user32: Implement WM_SETFONT margins in the CJK case.

[Akihiro Sagawa]

Fixes Bug 46685.
I'll send comctl32 (v6) fix, later.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46685
Signed-off-by: Akihiro Sagawa 
---
 dlls/user32/edit.c | 32 ++++++++++++++++++++++++++++++--
 1 file changed, 30 insertions(+), 2 deletions(-)

[Nikolay Sivov]

On 3/7/19 4:45 PM, Akihiro Sagawa wrote:
> +static BOOL get_cjk_font_margins(HDC hdc, BOOL unicode, SHORT *left, SHORT *right)
> +{
> - ABC abc[256];
> - UINT i;
> -
> - *left = *right = 0;
> - if (!unicode) {
> -
> if (!GetCharABCWidthsA(hdc, 0, 255, abc))
> -
> 	return FALSE;
> - } else {
> -
> if (!GetCharABCWidthsW(hdc, 0, 255, abc))
> -
> 	return FALSE;
> - }
> - for (i = 0; i < ARRAY_SIZE(abc); i++) {
> -
> if (-abc[i].abcA > *right) *right = -abc[i].abcA;
> -
> if (-abc[i].abcC > *left ) *left  = -abc[i].abcC;
> - }
> - return TRUE;
>
> +}

Is it possible to demonstrate this with some font, specifically modified 
to have one glyph significantly of?

It seems to me it's much more likely it would be using some averaged 
metric instead, specified by the font.

[Akihiro Sagawa]

On Thu, 7 Mar 2019 17:15:52 +0300, Nikolay Sivov wrote:
> On 3/7/19 4:45 PM, Akihiro Sagawa wrote:
> > +static BOOL get_cjk_font_margins(HDC hdc, BOOL unicode, SHORT *left, SHORT *right)
> > +{
> > - ABC abc[256];
> > - UINT i;
> > -
> > - *left = *right = 0;
> > - if (!unicode) {
> > -
> > if (!GetCharABCWidthsA(hdc, 0, 255, abc))
> > -
> > 	return FALSE;
> > - } else {
> > -
> > if (!GetCharABCWidthsW(hdc, 0, 255, abc))
> > -
> > 	return FALSE;
> > - }
> > - for (i = 0; i < ARRAY_SIZE(abc); i++) {
> > -
> > if (-abc[i].abcA > *right) *right = -abc[i].abcA;
> > -
> > if (-abc[i].abcC > *left ) *left  = -abc[i].abcC;
> > - }
> > - return TRUE;
> >
> > +}
>
> Is it possible to demonstrate this with some font, specifically modified 
> to have one glyph significantly of?

Thanks for reviewing.
I attached an archive file to Bug 46685[1]. It contains some test case
and modified Tahoma font. Could you look into that?

[1] https://bugs.winehq.org/show_bug.cgi?id=46685#c5
> It seems to me it's much more likely it would be using some averaged 
> metric instead, specified by the font.

Regarding to the test result, I think it's not true.
If WM_SETFONT used font metrics for margins, it would be no differences
between A and W versions.

Akihiro Sagawa

[Marvin]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?

Full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=48929

Your paranoid android.

=== debian9 (32 bit Chinese:China report) ===

user32:
edit.c:1838: Test failed: got 1
edit.c:1840: Test failed: got 1
edit.c:1848: Test failed: got 1
edit.c:1870: Test failed: got 2
edit.c:1894: Test failed: got 1

=== debian9 (64 bit WoW report) ===

user32:
msg.c:8713: Test failed: WaitForSingleObject failed 102
msg.c:8719: Test failed: destroy child on thread exit: 0: the msg 0x0082 was expected, but got msg 0x000f instead
msg.c:8719: Test failed: destroy child on thread exit: 1: the msg 0x000f was expected, but got msg 0x0014 instead
msg.c:8719: Test failed: destroy child on thread exit: 2: the msg sequence is not complete: expected 0014 - actual 0000