https://bugs.winehq.org/show_bug.cgi?id=39334
--- Comment #5 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Nikolay Sivov from comment #4)
Looks like it's a common case to have usWinDescent equal or very close to (-1)*sTypoDescender - that's a case for Arial, Tahoma, Times and Verdana from Windows and Symbol from macos. Regarding this particular font (and the ones Apple ships) I suspect that it's a font generator issue to set both fields to same value. If you suggest to use signed value and assume usWinDescent is negative in A+D calculations I don't think we should do that, but instead treat it as a normal font after manually fixing that value.
You are correct that in the most cases usWinDescent is supposed to have a positive value, and my tests under Windows confirm that. According to https://www.microsoft.com/typography/otspec/os2.htm#wd "usWinDescent is computed as the -yMin for all characters in the Windows ANSI character set." However, sometime it's appropriate to set yMin in this field: "If any clipping is unacceptable, then the value should be set to yMin." And that means that a negative value is not an error, but an intentional decision of the font designer or a font generation tool.
So, your patch Nikolay looks completely reasonable.