GNOME Bugzilla – Bug 735505
Weird Characters in Zoom Button
Last modified: 2015-12-14 17:56:11 UTC
Created attachment 284589 [details] weirdzoom see attachment
I'm witnessing the same problems on my install of 2.8.14 as well. Maybe a font file didn't get put into the Windows installer? Windows 7 x64 SP1 GIMP 2.8.14 x64
Disabling the MS-Windows theme engine prevents this - so it is likely a bug in GTK+ 2.24.23
I also see this issue on 2.8.14 (GIMP x32 on Windows 7 x64 SP1) I notice that the glyph that's being displayed says 2009 in the box this indicates that it's a misrendered U+2009 aka "thin space", if I manually copy the U+202F character aka "narrow no-break space" into the box it shows as I would have expected it to normally. I don't know that this the desired fix, but I doubt it would be too difficult for someone to find where that character is defined and replace the "thin space" with a "narrow no-break space".
I cannot confirm on Win7 64bit with GIMP 2.8.14 and GTK+-2.24.23 or GTK+-2.24.24 I can see a normal space between zoom level and %
what is it "GIMP 2.8.14 x64"? A build for Win 64 bit isn't here: http://download.gimp.org/pub/gimp/v2.8/windows/
The installer there contains both 32 bit and 64 bit versions.
and choose the right one on the basis of operative system. So seems impossible to install and test the 32 bit version on 64 bit OS, while in reality can work. Daniel how do you do that?
You can force it to install the 32 bit version, by providing /32 as a parameter to the installer on a command line.
I reported this, and the dll causing the fault, as part of bug 735501. The file at fault is libpango-1.0-0.dll. If you replace this with the version from Gimp 2.8.10 the bug is no longer present.
John, we want current versions of the libraries, not old ones, in current installers.
Obviously, I was merely pointing out the library at fault!
/32 is not documented in /HELP or /? usage. I retested on work PC Win7 64 bit. On this system still NOT happen neither with 32bit, neither with 64 bit version of GIMP. And neither happen with the old version packaged with GTK+-2.24.23 Maybe related to locale settings too, in my case Italian.
It might depend on the Windows UI font.
Created attachment 285501 [details] libpango version The default font used in my Win installation is Tahoma for all UI. I think this is used by GIMP zoom level drop down combo box too. I checked in Win Character Map, the codepoint U+2009 is a real thin white space. libpango-1.0-0.dll in my GIMP installation is 1.36.5.0 see attach
BTW: I cannot understand why not use a normal space U+0020 between numeric zoom level and %, this should work around this trouble
Created attachment 287099 [details] libpango version on a system exhibiting the issue Sorry I didn't get back right away, I actually am using GIMP Portable (from PortableApps.com) that's how I ended up with the 32-bit version even though I'm on a 64-bit PC. I'm just guessing here, but I think the purpose of using a thin space was to make it more likely that it will fit in the box even at ridiculously high zoom levels, though this doesn't seem to be necessary to me as the box is big enough (on my system) that even at the maximum zoom level it wouldn't be too big for the box if it were a normal space. I tried setting GIMP's locale to Italian, and I still see the issue. Windows' UI font is Segoe UI (the default for Windows 7) libpango is also 1.36.5.0 for me (see attachment)
Created attachment 287101 [details] libpango version from GIMP 2.8.10 If as John pointed out I swap in the libpango dll from GIMP 2.8.10 I no longer see the issue, though if I copy out the character it still appears to be U+2009, just rendering properly with the old libpango dll. For reference, the working libpango dll from GIMP 2.8.10 is version 1.34.0.0 (see attachment)
I can't edit my comment can I? My grammar could use some help in that last one. :( First, it looks like pango is up to 1.36.8 now, so if someone could find or build a newer version to test this with that would be nice. Second, from a quick look at the changelog https://git.gnome.org/browse/pango/tree/NEWS I'd guess the issue might be between 1.34 and 1.35 because of "Don't change fonts for space (#701652)". Could someone who's more familiar with programming check out that change? it's at https://git.gnome.org/browse/pango/commit/?id=d489ad061d70526fc5f5cdae2273e9deabea6a17
Yes, that change can totally do this *if* Pango is using win32 backend. Will be fixed (again) when we switch windows to use harfbuzz.
Thanks Behdad, I guess we will simply use a normal space for the time being.
As stated in Comment #3 I find that the "narrow no-break space" (U+202F) character is also rendered properly by more recent versions of Pango, so that is also an option if a 'thin'/'narrow' space is desired.
I checked the font Segoe UI, it miss the U+2009 gliph. In particular has: U+2002 short space U+2003 long space U+2007 numeric space U+2008 punctuation space U+200A ultra thin space U+200B zero width space So if really Win use Segue as default font, an alternative solution must be choosed. Note: On my Win7 the system as default for UI use Tahoma font that has the U+2009 thin space gliph plus the others spaces.
As pointed out by Michael Schumacher in Comment #2 "Disabling the MS-Windows theme engine prevents this". This is likely due to the Windows changing the font on a theme by theme basis. The "Windows Classic" theme sets the font to Tahoma, whereas the "Windows Basic" and "Windows 7" (aka Aero) themes use (by default) Segoe UI. Users can of course change their font either by changing Windows' theme or by setting their own custom font if they know where to go in the settings, but a fresh installation of Windows 7 with no settings changed from their default values will be using Segoe UI.
Users should not be required to do this, the problem is clearly on our side (in the pango DLL we ship). Let's just change the space. Behdad, how far in the future is the harfbuzz port of the windows backend? I'm wondering if I should change the space in both gimp-2-8 and master or only in gimp-2-8.
Fixed in master and gimp-2-8: commit 7e658a61db2d5b2c7ca3631ca0fdcec157e27383 Author: Michael Natterer <mitch@gimp.org> Date: Sat Sep 27 23:48:39 2014 +0200 Bug 735505 - Weird Characters in Zoom Button On windows, use a normal space instead of U+2009 THIN SPACE for separating the scale percentage from the percent sign. (cherry picked from commit c5ed3e56c9fabb3a93b39ef17f95e07172c83b98) app/display/gimpscalecombobox.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-)
I'm aiming for next major Pango release to use HarfBuzz only.
Thanks, I'll observe :)
Michael Natterer: I wasn't suggesting that users should be required to make such changes. I was explaining why Valerio Messina's copy of Windows 7 may not have been using the default Windows 7 font, despite Valerio having (most likely) not directly changed Windows' font setting. Also thanks for making the change, I look forward to seeing it in the next version. Behdad Esfahbod: HarfBuzz looks nice, keep up the good work.
*** Bug 738577 has been marked as a duplicate of this bug. ***
*** Bug 739014 has been marked as a duplicate of this bug. ***
*** Bug 739505 has been marked as a duplicate of this bug. ***
(In reply to comment #22) > So if really Win use Segue as default font, an alternative solution must be > choosed. I disagree: For example there is a TTF font validator (from Microsoft), and when applied to TTF fonts that come with Windows, the validator finds many issues. Tell Microsoft to fix their problems, not work around the bugs all the time. If TeX knew about different spaces 20 years ago at least, it's time for Microsoft to catch up...
The libraries we use are supposed to work around this by design, though - if a glyph isn't found in one font, it is supposed to be taken from a different, preferably similar one. This is a regression in Pango.
yes, this is true. I just installed the MS font validator, and runt on arial.ttf updated to september 2014, most are green and yellow lines so ok and warn, but it complaint with about 200 red lines (Error) in LTSH section, one in OS/2 section and about 1500 in VDMX section. MS is always funny. Thank you for the info. Try to complaint with MS asking a fix fo this.
*** Bug 739851 has been marked as a duplicate of this bug. ***
*** Bug 751525 has been marked as a duplicate of this bug. ***
still no Win release to include this fix?
Valerio Messina, whenever 2.8.15 is ready, it'll be fixed in that. I tried a recent nightly and its fixed, but I'd rather wait for the installer.
Windows 2.8.15 is ready but not available at: http://www.gimp.org/downloads/ neither at: http://ftp.gnome.org/Public/gimp/gimp/v2.8/
No, it isn't. The next release will be 2.8.16. The version number 2.8.15 - and any other odd micro version - is used for the time in between releases.
many collegues hit this zoom bug and complaint to me, so trepidation waiting for official 2.8.16 bug fix release
tested on WinXP 32 bit and Win7 64 bit. XP has no U+2009 narrow space in neither Tahoma nor Segoe UI, while 7 has it in Tahoma only. GIMP 2.8.16 show a (normal) space before % in zoom text box on both Win OS
Yes that's the expected appearance now on windows.