[Bug 39334] New: comctl32 status bar test crashes on Linux if Bubbler One font is installed
https://bugs.winehq.org/show_bug.cgi?id=39334
Bug ID: 39334 Summary: comctl32 status bar test crashes on Linux if Bubbler One font is installed Product: Wine Version: 1.7.51 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs@winehq.org Reporter: alexhenrie24@gmail.com Distribution: ---
Created attachment 52414 --> https://bugs.winehq.org/attachment.cgi?id=52414 trace+font
To reproduce: 1. Install typecatcher. 2. Use typecatcher to install the Bubbler One font. You can also download the font from https://github.com/google/fonts/blob/master/ofl/bubblerone/BubblerOne-Regula... 3. Run `./wine dlls/comctl32/tests/comctl32_test.exe.so status`.
I initially thought that the crash was being caused by a bitmap font from Xorg, but Bubbler One is actually a vector font from Google.
The problem is reproducible on both Lubuntu 15.04 x86 and Arch Linux x64.
Installing Bubbler One on Windows does not cause the test to crash.
https://bugs.winehq.org/show_bug.cgi?id=39334
Alex Henrie alexhenrie24@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dmitry@baikal.ru
https://bugs.winehq.org/show_bug.cgi?id=39334
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com --- The issue seems to be about large usWinDescent value, section of OS/2 table:
--- 'OS/2' version: 2 ... fsSelection: 0x0040 ... sTypoAscender: 900 sTypoDescender: -263 ... usWinAscent: 900 usWinDescent: 65273 ---
Later this part:
--- ppem = MulDiv(ft_face->units_per_EM, height, pOS2->usWinAscent + pOS2->usWinDescent); ---
produces 0, because unitsPerEm is 1000 for this font, so for not large enough height result will be always zero.
Similar thing happens on MacOS (with different font), as current test page shows.
https://bugs.winehq.org/show_bug.cgi?id=39334
--- Comment #2 from Nikolay Sivov bunglehead@gmail.com --- Created attachment 52428 --> https://bugs.winehq.org/attachment.cgi?id=52428 patch
Hi, Alex.
Try this one please.
https://bugs.winehq.org/show_bug.cgi?id=39334
--- Comment #3 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Nikolay Sivov from comment #1)
The issue seems to be about large usWinDescent value, section of OS/2 table:
'OS/2' version: 2 ... fsSelection: 0x0040 ... sTypoAscender: 900 sTypoDescender: -263 ... usWinAscent: 900 usWinDescent: 65273
The source of the problem is that in the freetype/tttables.h TT_OS2 structure has FT_SHORT sTypoDescender; FT_USHORT usWinDescent;
So, probably the most easiest fix would be to treat usWinDescent as signed value. After all: -263 == 0xfef9 65273 == 0xfef9
https://bugs.winehq.org/show_bug.cgi?id=39334
--- Comment #4 from Nikolay Sivov bunglehead@gmail.com --- 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.
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.
https://bugs.winehq.org/show_bug.cgi?id=39334
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |af5884ffe5a8ba50630cf8e180d | |db4d700d8117a Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #6 from Nikolay Sivov bunglehead@gmail.com --- Fixed with af5884ffe5a8ba50630cf8e180ddb4d700d8117a.
https://bugs.winehq.org/show_bug.cgi?id=39334
--- Comment #7 from Alex Henrie alexhenrie24@gmail.com --- The tests don't crash for me anymore, thank you!
https://bugs.winehq.org/show_bug.cgi?id=39334
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.52.
-
wine-bugs＠winehq.org