[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(a)winehq.org Reporter: alexhenrie24(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39334 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmitry(a)baikal.ru -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39334 --- Comment #1 from Nikolay Sivov <bunglehead(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39334 --- Comment #2 from Nikolay Sivov <bunglehead(a)gmail.com> --- Created attachment 52428 --> https://bugs.winehq.org/attachment.cgi?id=52428 patch Hi, Alex. Try this one please. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39334 --- Comment #3 from Dmitry Timoshkov <dmitry(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39334 --- Comment #4 from Nikolay Sivov <bunglehead(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39334 --- Comment #5 from Dmitry Timoshkov <dmitry(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39334 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |af5884ffe5a8ba50630cf8e180d | |db4d700d8117a Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Nikolay Sivov <bunglehead(a)gmail.com> --- Fixed with af5884ffe5a8ba50630cf8e180ddb4d700d8117a. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39334 --- Comment #7 from Alex Henrie <alexhenrie24(a)gmail.com> --- The tests don't crash for me anymore, thank you! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=39334 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #8 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 1.7.52. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org