http://bugs.winehq.org/show_bug.cgi?id=32334
Bug #: 32334 Summary: Microsoft SQL Server Management Studio Express 2005: Connection window is too narrow Product: Wine Version: 1.5.18 Platform: x86 URL: http://www.microsoft.com/download/en/details.aspx?id=8 961 OS/Version: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: djelinski1@gmail.com Classification: Unclassified Regression SHA1: ebaf5ea17623268fb1c0f68b1cf9a5984bd4e46e
Created attachment 42678 --> http://bugs.winehq.org/attachment.cgi?id=42678 Screenshots of good and bad versions
Connection window that appears right after starting the application is too narrow. You may notice that the bitmap on the top is clipped.
Regression testing points to the following commit: ebaf5ea17623268fb1c0f68b1cf9a5984bd4e46e is the first bad commit commit ebaf5ea17623268fb1c0f68b1cf9a5984bd4e46e Author: Alexandre Julliard julliard@winehq.org Date: Thu Nov 15 13:29:21 2012 +0100
gdi32: Don't load bitmap glyphs when using subpixel rendering in GetGlyphOutline.
Reverting that commit on top of current git brings back correct behavior.
Prerequisite: winetricks dotnet20 win7
http://bugs.winehq.org/show_bug.cgi?id=32334
Daniel Jelinski djelinski1@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dotnet, download, | |regression
http://bugs.winehq.org/show_bug.cgi?id=32334
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression | Regression SHA1|ebaf5ea17623268fb1c0f68b1cf | |9a5984bd4e46e |
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2012-11-30 16:35:23 CST --- That's because the metrics of our Tahoma font aren't quite correct. Technically not a regression, it works fine with the Windows one.
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #2 from Daniel Jelinski djelinski1@gmail.com 2012-12-01 13:13:38 CST --- May be a duplicate of bug 30728 then. I don't have access to windows Tahoma to verify.
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #3 from Alexandre Julliard julliard@winehq.org 2012-12-01 14:22:12 CST --- Windows Tahoma doesn't fix bug 30728, so it's probably not entirely the same problem.
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #4 from Daniel Jelinski djelinski1@gmail.com 2012-12-01 14:23:29 CST --- Thank you very much for checking
http://bugs.winehq.org/show_bug.cgi?id=32334
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |fonts
http://bugs.winehq.org/show_bug.cgi?id=32334
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |support@securenetterm.com
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2012-12-23 17:42:58 CST --- *** Bug 32529 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #6 from Kenneth Robinette support@securenetterm.com 2012-12-24 07:10:32 CST --- I don't see a bug report on the Tahoma font metrics. Are there plans to fix that font, or is the real Windows fonts always going to be required for any application that has dialogs and other requirements for the Tahoma font.
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #7 from Dmitry Timoshkov dmitry@baikal.ru 2012-12-24 08:07:15 CST --- (In reply to comment #6)
I don't see a bug report on the Tahoma font metrics. Are there plans to fix that font, or is the real Windows fonts always going to be required for any application that has dialogs and other requirements for the Tahoma font.
It's impossible to fix for technical reasons without copying complete outlines along with accompanied bytecode hinting instructions for every glyph.
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #8 from Dmitry Timoshkov dmitry@baikal.ru 2012-12-24 08:08:27 CST --- That's the whole point of having embedded bitmaps for small point sizes.
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #9 from Kenneth Robinette support@securenetterm.com 2012-12-24 08:41:39 CST --- This does not make sense. Applications that have dialogs that do not render correctly in versions 1.5.18 and above work perfectly in version 1.5.17 and below. So if the Tahoma font cannot be fixed, that implies it was the same in version 1.5.17 as it is in version 1.5.20. So what changed?
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #10 from Nikolay Sivov bunglehead@gmail.com 2012-12-24 08:43:22 CST --- (In reply to comment #9)
This does not make sense. Applications that have dialogs that do not render correctly in versions 1.5.18 and above work perfectly in version 1.5.17 and below. So if the Tahoma font cannot be fixed, that implies it was the same in version 1.5.17 as it is in version 1.5.20. So what changed?
If you think something changed you could always do a regression test.
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #11 from Kenneth Robinette support@securenetterm.com 2012-12-24 08:58:05 CST --- I did, see bug 32529 (which was marked by Alexandre as a duplicate of this). So we have a catch 22 here. Alexandre states it really is not a regression since it is a problem with the Tahoma font metrics, which can't be fixed. If the font used in dialogs worked ok in version 1.5.17, why do they fail in 1.5.18 and above?
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #12 from Alexandre Julliard julliard@winehq.org 2012-12-24 08:59:51 CST --- Because we used to use the bitmaps, and now we use the outlines so that we can do antialiasing.
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #13 from Dmitry Timoshkov dmitry@baikal.ru 2012-12-24 09:01:37 CST --- (In reply to comment #9)
This does not make sense. Applications that have dialogs that do not render correctly in versions 1.5.18 and above work perfectly in version 1.5.17 and below. So if the Tahoma font cannot be fixed, that implies it was the same in version 1.5.17 as it is in version 1.5.20. So what changed?
Changelog of the commit that has caused this regression explains it:
gdi32: Don't load bitmap glyphs when using subpixel rendering in GetGlyphOutline.
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #14 from Kenneth Robinette support@securenetterm.com 2012-12-24 09:32:14 CST --- So the bottom line is all developers of Windows based applications that have dialogs must either do a real time detection of WINE, then customize their dialogs to run correctly under WINE or recommend that companies that run these applications pay a royalty to Microsoft to use their copyrighted Tahoma truetype font.
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #15 from Dmitry Timoshkov dmitry@baikal.ru 2012-12-24 09:36:25 CST --- (In reply to comment #14)
So the bottom line is all developers of Windows based applications that have dialogs must either do a real time detection of WINE, then customize their dialogs to run correctly under WINE or recommend that companies that run these applications pay a royalty to Microsoft to use their copyrighted Tahoma truetype font.
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #16 from Dmitry Timoshkov dmitry@baikal.ru 2012-12-24 09:36:44 CST --- (In reply to comment #14)
So the bottom line is all developers of Windows based applications that have dialogs must either do a real time detection of WINE, then customize their dialogs to run correctly under WINE or recommend that companies that run these applications pay a royalty to Microsoft to use their copyrighted Tahoma truetype font.
That conclusion is completely wrong.
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #17 from Kenneth Robinette support@securenetterm.com 2012-12-26 19:16:17 CST --- If that conclusion is not correct, then what is the official WINE method to maintain Windows dialog compatibly?
http://bugs.winehq.org/show_bug.cgi?id=32334
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #18 from Dmitry Timoshkov dmitry@baikal.ru 2012-12-26 22:22:11 CST --- (In reply to comment #17)
If that conclusion is not correct, then what is the official WINE method to maintain Windows dialog compatibly?
This bug is still open, it's not been resolved as WONTFIX or INVALID.
http://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #19 from Daniel Jelinski djelinski1@gmail.com 2012-12-27 03:41:48 CST --- Created attachment 42967 --> http://bugs.winehq.org/attachment.cgi?id=42967 Splash screen before and after
There's more to this bug than just incorrect metrics, it seems that it also made calculating text extents inconsistent with drawing text. See attached screenshots: - the window size is calculated based on font metrics in such a way that all text should fit without wrapping - but then the text does not fit into the calculated area. Good screenshot was taken from current git with commit ebaf5ea17623268fb1c0f68b1cf9a5984bd4e46e reverted, bad is current git. Screenshots were taken from sql server 2008 installer.
http://bugs.winehq.org/show_bug.cgi?id=32334
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |guy.roussin@teledetection.f | |r
--- Comment #20 from Alexandre Julliard julliard@winehq.org 2013-03-09 17:26:41 CST --- *** Bug 33154 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=32334
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |imwellcushtymelike@gmail.co | |m
--- Comment #21 from Ken Sharp imwellcushtymelike@gmail.com --- *** Bug 35249 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=32334
Don Pobanz dpobanz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dpobanz@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #22 from Ken Sharp imwellcushtymelike@gmail.com --- BOINC doesn't seem to have any issues related to this bug in Wine 1.7.33. Can someone please test another application affected?
https://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #23 from Daniel Jelinski djelinski1@gmail.com --- My original issue from comment 1 was fixed by upgrading my distro. With the new one I'm unable to reproduce the narrow connection settings window even in the originally reported version. Most likely a freetype issue.
The issue with Tahoma font metrics still stands though, so I'm not sure if I should close this bug or keep it open...
https://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #24 from Ken Sharp imwellcushtymelike@gmail.com --- Reappeared in wine-1.8-rc1 but might be because of a different machine. As above anyway.
https://bugs.winehq.org/show_bug.cgi?id=32334
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle@yahoo.fr
https://bugs.winehq.org/show_bug.cgi?id=32334
--- Comment #25 from Ken Sharp imwellcushtymelike@gmail.com --- Ping: is this still an issue? I don't know how to test this further.
https://bugs.winehq.org/show_bug.cgi?id=32334
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source
--- Comment #26 from Ken Sharp imwellcushtymelike@gmail.com --- Turns out I can recreate this with the BOINC Manager (I think):
The fonts in the task list are always slightly off-screen to the right. "winetricks tahoma" solves this.
sha1sum: c77c4674b16ae64c27aa8666af3e68b25a3661cc boinc_7.22.2_windows_x86_64.exe
BOINC is open source.