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

[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