After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 735505 - Weird Characters in Zoom Button
Weird Characters in Zoom Button
Product: GIMP
Classification: Other
Component: User Interface
Other Windows
: Normal minor
: 2.8
Assigned To: GIMP Bugs
: 738577 739014 739505 739851 751525 (view as bug list)
Depends on:
Reported: 2014-08-27 09:18 UTC by gedon
Modified: 2015-12-14 17:56 UTC
See Also:
GNOME target: ---
GNOME version: ---

weirdzoom (6.02 KB, image/jpeg)
2014-08-27 09:18 UTC, gedon
libpango version (15.34 KB, image/png)
2014-09-05 14:36 UTC, Valerio Messina
libpango version on a system exhibiting the issue (22.23 KB, image/png)
2014-09-25 18:03 UTC, Daniel Preston
libpango version from GIMP 2.8.10 (22.64 KB, image/png)
2014-09-25 18:11 UTC, Daniel Preston

Description gedon 2014-08-27 09:18:05 UTC
Created attachment 284589 [details]

see attachment
Comment 1 rickmastfan67 2014-08-27 10:39:37 UTC
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
Comment 2 Michael Schumacher 2014-08-27 22:04:46 UTC
Disabling the MS-Windows theme engine prevents this - so it is likely a bug in
GTK+ 2.24.23
Comment 3 Daniel Preston 2014-09-03 20:36:07 UTC
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".
Comment 4 Valerio Messina 2014-09-04 16:37:11 UTC
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 %
Comment 5 Valerio Messina 2014-09-04 16:41:24 UTC
what is it "GIMP 2.8.14 x64"?
A build for Win 64 bit isn't here:
Comment 6 Michael Schumacher 2014-09-04 19:47:22 UTC
The installer there contains both 32 bit and 64 bit versions.
Comment 7 Valerio Messina 2014-09-04 20:47:12 UTC
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?
Comment 8 Michael Schumacher 2014-09-04 20:56:56 UTC
You can force it to install the 32 bit version, by providing /32 as a parameter to the installer on a command line.
Comment 9 John Power 2014-09-04 21:26:04 UTC
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.
Comment 10 Michael Schumacher 2014-09-04 21:29:49 UTC
John, we want current versions of the libraries, not old ones, in current installers.
Comment 11 John Power 2014-09-04 21:32:08 UTC
Obviously, I was merely pointing out the library at fault!
Comment 12 Valerio Messina 2014-09-05 12:00:38 UTC
/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.
Comment 13 Michael Schumacher 2014-09-05 13:13:57 UTC
It might depend on the Windows UI font.
Comment 14 Valerio Messina 2014-09-05 14:36:08 UTC
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 see attach
Comment 15 Valerio Messina 2014-09-05 14:43:26 UTC
BTW: I cannot understand why not use a normal space U+0020 between numeric zoom level and %, this should work around this trouble
Comment 16 Daniel Preston 2014-09-25 18:03:57 UTC
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 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 for me (see attachment)
Comment 17 Daniel Preston 2014-09-25 18:11:47 UTC
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 (see attachment)
Comment 18 Daniel Preston 2014-09-25 21:50:22 UTC
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 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
Comment 19 Behdad Esfahbod 2014-09-25 22:06:56 UTC
Yes, that change can totally do this *if* Pango is using win32 backend.  Will be fixed (again) when we switch windows to use harfbuzz.
Comment 20 Michael Natterer 2014-09-26 07:37:49 UTC
Thanks Behdad, I guess we will simply use a normal space for the time
Comment 21 Daniel Preston 2014-09-26 16:20:47 UTC
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.
Comment 22 Valerio Messina 2014-09-26 17:03:58 UTC
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.
Comment 23 Daniel Preston 2014-09-27 20:30:17 UTC
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.
Comment 24 Michael Natterer 2014-09-27 21:26:31 UTC
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.
Comment 25 Michael Natterer 2014-09-27 22:14:02 UTC
Fixed in master and gimp-2-8:

commit 7e658a61db2d5b2c7ca3631ca0fdcec157e27383
Author: Michael Natterer <>
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(-)
Comment 26 Behdad Esfahbod 2014-09-29 13:38:38 UTC
I'm aiming for next major Pango release to use HarfBuzz only.
Comment 27 Michael Natterer 2014-09-29 20:11:22 UTC
Thanks, I'll observe :)
Comment 28 Daniel Preston 2014-10-05 20:33:18 UTC
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.
Comment 29 Michael Schumacher 2014-10-15 20:56:27 UTC
*** Bug 738577 has been marked as a duplicate of this bug. ***
Comment 30 Michael Natterer 2014-10-22 18:39:20 UTC
*** Bug 739014 has been marked as a duplicate of this bug. ***
Comment 31 Michael Schumacher 2014-11-01 18:42:19 UTC
*** Bug 739505 has been marked as a duplicate of this bug. ***
Comment 32 Ulrich.Windl 2014-11-07 07:59:18 UTC
(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...
Comment 33 Michael Schumacher 2014-11-07 08:46:06 UTC
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.
Comment 34 Valerio Messina 2014-11-07 14:25:15 UTC
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.
Comment 35 Michael Schumacher 2014-11-10 11:41:18 UTC
*** Bug 739851 has been marked as a duplicate of this bug. ***
Comment 36 Michael Natterer 2015-06-26 08:07:10 UTC
*** Bug 751525 has been marked as a duplicate of this bug. ***
Comment 37 Valerio Messina 2015-07-02 16:10:29 UTC
still no Win release to include this fix?
Comment 38 TigerNightmare 2015-07-02 23:38:15 UTC
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.
Comment 39 Valerio Messina 2015-07-04 20:42:29 UTC
Windows 2.8.15 is ready but not available at:
neither at:
Comment 40 Michael Schumacher 2015-07-05 13:02:56 UTC
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.
Comment 41 Valerio Messina 2015-07-06 08:28:09 UTC
many collegues hit this zoom bug and complaint to me,
so trepidation waiting for official 2.8.16 bug fix release
Comment 42 Valerio Messina 2015-12-14 16:37:34 UTC
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
Comment 43 Michael Natterer 2015-12-14 17:56:11 UTC
Yes that's the expected appearance now on windows.