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 787867 - OSX macports pango text size appears to vary between version 1.40.12 (bad) and 1.40.6 (good)
OSX macports pango text size appears to vary between version 1.40.12 (bad) an...
Status: RESOLVED FIXED
Product: pango
Classification: Platform
Component: general
1.40.x
Other Mac OS
: Normal normal
: ---
Assigned To: John Ralls
pango-maint
Depends on:
Blocks:
 
 
Reported: 2017-09-19 00:43 UTC by mathewp
Modified: 2018-11-14 06:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Restore 96ppi scaling (6.44 KB, patch)
2018-04-29 23:07 UTC, John Ralls
committed Details | Review
pango 1.42.1 and gtk 3.22.30 (969.52 KB, image/png)
2018-07-20 11:23 UTC, Tom Schoonjans
  Details
pango 1.42.2 and gtk 3.22.30 (1.27 MB, image/png)
2018-07-20 11:24 UTC, Tom Schoonjans
  Details
pango 1.42.2 and gtk 3.22.30 patched with John's [PATCH] [Quartz] Hardcode screen resolution for text at 96.0. (1.05 MB, image/png)
2018-07-20 11:25 UTC, Tom Schoonjans
  Details
Screenshot of gtk3-widget-factory, bibdesk and pages (2.14 MB, image/png)
2018-07-20 14:25 UTC, Tom Schoonjans
  Details
gtk3-demo on MacBookPro Retina with gtk3.22.30 patched (with Johns patch) and pango 1.42.4 (710.73 KB, image/jpeg)
2018-11-13 09:54 UTC, Friedrich Beckmann
  Details
gtk3-demo on MacBookPro Retina with gtk3.22.30 patched (with Johns patch) and pango 1.42.4 with system font size 10 (797.38 KB, image/jpeg)
2018-11-13 10:10 UTC, Friedrich Beckmann
  Details
gtk3-demo on MacBookPro Retina with gtk3.22.30 patched (with Johns patch) changed to 72dpi and pango 1.42.4 - perfekt result (581.49 KB, image/jpeg)
2018-11-13 21:27 UTC, Friedrich Beckmann
  Details

Description mathewp 2017-09-19 00:43:49 UTC
I spent some time diagnosing a problem with dot (graphviz) and suspect the issue to be a regression in Pango.  I noted that two similar Mac OSX systems produced different SVGs from the same dot file and same version of graphviz, on one the text was not contained in the bounding box and on the other machine it was.  I was able to reproduce the problem in a single line graph.dot file.  On machine 1 the rectangle around the text had the correct width (even spacing, text inside bounding box), and on machine 2 the text width appears to be incorrect (uneven in my one line example, text spilling outside the bounding box on longer strings).  Long story short, just downgrading the macports pango from version 1.40.12 to 1.40.6 solved the problem.

Steps to reproduce:
1. Create a one line test.dot graphviz file: digraph G { A [label="Hello World", shape=rectangle]; }
2. dot test.dot -T svg -v

Machine 1. With pango 1.40.6 (good):

…
<polygon fill="none" stroke="#000000" points="87,-36 0,-36 0,0 87,0 87,-36"/>
…

Machine 2. With pango 1.40.12 (bad):

…
<polygon fill="none" stroke="#000000" points="69,-36 0,-36 0,0 69,0 69,-36"/>
…

Note the different bounding box widths.  In both cases the verbose console output from dot shows the fonts resolving to the same fontname and size etc:
 
 fontname: "Times-Roman" resolved to: (ps:pango  Times,  REGULAR) (PangoCairoCoreTextFont) "Times"

Reverting just the pango version from 1.40.12 to 1.40.6 on machine 2 solved the problem, it then produced the same good output as machine 1.  If I re-activate the MacPort 1.40.12 version, the problem comes back.  It is reproducible.

OS: MacOS Sierra
MacPorts: 2.4.1
Graphviz: graphviz @2.40.1_1+pangocairo+x11
Pango: pango @1.40.6_0+quartz+x11 (good), pango @1.40.12_0+quartz+x11 (bad)
Comment 1 Behdad Esfahbod 2017-09-20 17:17:53 UTC
Looks like fallout from https://bugzilla.gnome.org/show_bug.cgi?id=782393
Comment 2 John Ralls 2017-09-23 03:41:46 UTC
Yup. I confirmed that first by reverting 8ab2cc19 and then to narrow it down by restoring 
  if (!pango_font_description_get_size_is_absolute (desc))
  {
     double dpi = pango_core_text_font_map_get_resolution (fontmap, context);
     size = size * dpi / 72.;
  }
to get_scaled_size() in pangocoretext-fontmap.c. 

graphviz is calling pango_cairo_context_set_resolution(96)
at https://github.com/ellson/graphviz/blob/master/plugin/pango/gvtextlayout_pango.c#L56
and then divides it back out at https://github.com/ellson/graphviz/blob/master/plugin/pango/gvtextlayout_pango.c#L245
to get the extent of the line. Since removing the "is_absolute" code means that the extent isn't blown up in the first place reducing it afterwards does the wrong thing.

I guess that since pango_cairo_context_set_resolution is generic for all pangocairo backends that this makes sense somewhere even though it doesn't for CoreText...though it seems a bit weird to tell the user "give us a number to multiply the measurements by so that you can divide it back out again".

Only pangocairo_context has a set_resolution so it seems to me that it should be pangocairo_fontmap that does the multiplying rather than pangocoretext_fontmap even though it appears that (at present anyway) only pangocairo is able to use pangocoretext. I propose that the pangocairo_coretext default resolution should be 72 because that's what the Apple drivers think it should be (as I pointed out in bug 782393 CoreText takes care of adjusting resolution for "Retina" displays at a lower level so there's no need for Pango or Pango clients to worry about it).

Behdad, does that seem like a reasonable approach?
Comment 3 Behdad Esfahbod 2017-10-01 16:19:36 UTC
The real bug seems to be the fact that pangocoretext does not implement implement describe_absolute(), so the set resolution (96) is not applied.  If we can change describe_absolute() to reflect that then you'd be good.

Most of your changes are correct still: the fact that coretext API takes point sizes not pixels...

Humm.  I see how that wouldn't fix the problem, because as you said, someone needs to scale things...

I'm not sure how to fix this.

> Only pangocairo_context has a set_resolution so it seems to me that it should
> be pangocairo_fontmap that does the multiplying rather than
> pangocoretext_fontmap

Agreed.

> I propose that the pangocairo_coretext default resolution should be 72

How does that fix the issue though?  They are explicitly setting to 96.
Comment 4 John Ralls 2017-10-01 16:49:04 UTC
(In reply to Behdad Esfahbod from comment #3)

> > I propose that the pangocairo_coretext default resolution should be 72
> 
> How does that fix the issue though?  They are explicitly setting to 96.

In combination with pangocairo_fontmap multiplying the size by dpi/72. If pangocairo_context's default resolution is 72 then that would multiply the size by 1 unless the client changes the resolution as graphviz does.

OTOH there may be user code out there that assumes that the default is 96 and never sets it but still divides it back out from the returned size. In that case it would be better to revert the removal of coretext's describe_absolute() and the change of the coretext default dpi and do the gtkwidget hack I mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=782393#c1.
Comment 5 parafin 2017-10-18 14:08:46 UTC
Coming from https://bugzilla.gnome.org/show_bug.cgi?id=782393#c18, didn't find this one before, sorry.

The issue I have is that after 8ab2cc19 it's impossible to get pango to scale fonts with coretext backend. Before one could use gdk_screen_set_resolution (or some other way if using pango directly instead of gtk) to set desired DPI setting, now it doesn't do anything. If you set PANGOCAIRO_BACKEND=fc you can see fontconfig backend working correctly (but failing with out of memory errors on my system, but that's unrelated to this issue). Please fix this. The fact that default DPI on Mac is 72 is not a good reason to remove a functionality to set other values (which worked before).
Comment 6 John Ralls 2017-10-19 00:58:28 UTC
The rationale for removing it was that Quartz knows (on internal monitors, anyway) what resolution to use and takes care of it. CoreText doesn't actually expose any scaling API: You tell it what size font you want in points and it displays that size on the screen, providing the screen is an internal monitor. Doesn't work for squat on my Mac Pro because Quartz has no idea what size or resolutions the screens are, but that has nothing to do with Pango.

If you put back just the snippet in comment 2 (it goes at line 829 in pangocoretext-fontmap.c) does it behave the way you want?
Comment 7 parafin 2017-10-19 08:25:48 UTC
yes, just returning those 5 lines fixes my problem
Comment 8 Behdad Esfahbod 2017-10-19 18:24:26 UTC
I believe I caused much of this trouble, as I gave John wrong advice.

I was under the impression that CoreText takes font size in typographic points, which are 72 per inch.  However, last week, as part a convoluted debugging of another issue and contacting CoreText and Webkit engineers, it became clear to me that CoreGraphics and CoreText points are in fact CSS pixels, ie. 96 per inch.  I hope that explains the disparity here.  So, looks like we need to do a multiplication by 96./72. when creating CTFont.

John, does this help?
Comment 9 John Ralls 2017-10-20 02:54:01 UTC
Behdad,

Not really. We only create a CTFont to turn it into a CGFont that we pass to cairo to create a cairofont. (The CGFont API, while it hasn't gone away, is no longer documented. It's probably past time to rewrite cairoquartz-font.c to the CoreText API, but that's off-topic for this bug.) IIUC cairo takes care of setting up the font from the CGFont metrics. I have no idea what units those metrics use, perhaps that's where the CSS pixels come in. The CoreText API documentation only has points. I'd think that means that conversion to pixels, whether CSS or physical, happens at a lower level.

FWIW after more study of the GdkScreen code and in light of what I've learned from these two pango bugs I think I made a mistake on the gdk-quartz side by believing that the original design was correct and the implementation broken; in fact the design was broken and the implementation failure that always returned a scale factor of 1 was correct. If I fix that and either revert 8ab2cc or just restore the 5 lines to get_scaled_size then all of the complaints so far will be resolved.

What's your pleasure?
Comment 10 Behdad Esfahbod 2017-10-20 17:34:12 UTC
I don't follow the details, but if you say so, sounds good to me.  Do note, as I said, CoreText points are not typographic points, they are CSS pixels.
Comment 11 John Ralls 2017-10-20 22:54:31 UTC
OK. It would be nice if that was better documented.

I think that means I should revert 8ab2cc.

Should pango_core_text_font_map_get_resolution return 96 instead of 72 if PANGO_CORE_TEXT_FONT_MAP_GET_CLASS (fontmap)->get_resolution) isn't defined? By extension, should GdkScreen::resolution be 96 instead of 72? IMO it does improve the look a bit. I haven't yet checked with dot or on Retina...
Comment 12 parafin 2017-12-20 20:41:25 UTC
So... A couple of releases have passed, just pinging to see if you forgotten about this issue.
Comment 13 John Ralls 2017-12-21 01:27:59 UTC
I haven't forgotten. Perhaps Behdad doesn't realize that I'm waiting for him to say whether he wants me to revert all of the pixel->point change or just the get_scaled_size change.
Comment 14 Behdad Esfahbod 2018-02-08 22:34:01 UTC
(In reply to John Ralls from comment #13)
> I haven't forgotten. Perhaps Behdad doesn't realize that I'm waiting for him
> to say whether he wants me to revert all of the pixel->point change or just
> the get_scaled_size change.

I don't have a good enough grasp to tell you one way or another.

What I can tell is this: CoreText works in CSS pixels, which are hardcoded as being 4./3. typographic points.  So, no, I don't think the pixel->point change needs to be reverted. Just add a 4./3. conversion when converting to/from CoreText points.

Does that make sense?
Comment 15 John Ralls 2018-02-09 03:31:04 UTC
OK, 4/3 (i.e. 96 CSS pixels per CoreText point), CoreText takes care of scaling for Retina. That's the default, so if the caller sets a different value then honor it.

I'll work up a patch.
Comment 16 John Ralls 2018-04-12 13:58:37 UTC
*** Bug 795188 has been marked as a duplicate of this bug. ***
Comment 17 John Ralls 2018-04-29 23:07:43 UTC
Created attachment 371525 [details] [review]
Restore 96ppi scaling

Sorry this took so long, GnuCash has consumed all of my cycles for the last several months.

I think this does the right thing: One effect (that should probably have been a red flag in the first place) is that the font size doesn't need to be fiddled in test-layout.
Comment 18 Behdad Esfahbod 2018-05-01 00:04:30 UTC
Looks good to me, but that shouldn't mean much. :)
Comment 19 John Ralls 2018-05-01 03:09:39 UTC
Anyone else want to weigh in?
Comment 20 John Ralls 2018-05-09 00:57:15 UTC
Comment on attachment 371525 [details] [review]
Restore 96ppi scaling

Not having heard from anyone else, I've pushed the changes.
Comment 21 Christoph Reiter (lazka) 2018-06-17 16:37:12 UTC
Are there any more pending patches related to this?

With current gtk3 the css font sizes are wrong so I tried to backport this patch, but it doubles the size of all text.
Comment 22 John Ralls 2018-06-17 16:57:40 UTC
https://gitlab.gnome.org/GNOME/gtk/commit/828f634d5c08b9c39626dd1512ec7a1af4800f3d is the corresponding commit to gdk-quartz to hard-code that to 96 DPI as well. It will be in gtk 3.22.31.

I haven't cherry-picked it over to master or gtk-3-24.
Comment 23 Christoph Reiter (lazka) 2018-06-17 17:00:39 UTC
Thanks! I'll give that a try :)
Comment 24 Christoph Reiter (lazka) 2018-06-21 16:44:16 UTC
Sadly css size is still broken with that patch in normal mode and with hidpi it segfaults right away:

0   libobjc.A.dylib               	0x00007fff661c25a9 objc_msgSend_stret + 41
1   libgdk-3.0.dylib              	0x000000010904a774 gdk_quartz_monitor_get_workarea + 132
2   libgdk-3.0.dylib              	0x000000010901343a gdk_monitor_get_workarea + 282
3   libgtk-3.0.dylib              	0x000000010bff72b6 gtk_window_guess_default_size + 118
4   libgtk-3.0.dylib              	0x000000010bff6be5 gtk_window_compute_configure_request_size + 101
5   libgtk-3.0.dylib              	0x000000010bfe51f0 gtk_window_compute_configure_request + 96
6   libgtk-3.0.dylib              	0x000000010bff40f3 gtk_window_move_resize + 115
7   libgtk-3.0.dylib              	0x000000010bff1cb6 gtk_window_check_resize + 134
8   libgobject-2.0.0.dylib        	0x00000001075e3d20 g_cclosure_marshal_VOID__VOIDv + 176
9   libgobject-2.0.0.dylib        	0x00000001075e0a72 g_type_class_meta_marshalv + 146
10  libgobject-2.0.0.dylib        	0x00000001075dff9b _g_closure_invoke_va + 539
11  libgobject-2.0.0.dylib        	0x0000000107601409 g_signal_emit_valist + 1801
12  libgobject-2.0.0.dylib        	0x0000000107602bc4 g_signal_emit + 356
13  libgtk-3.0.dylib              	0x000000010bc73456 gtk_container_check_resize + 198
14  libgtk-3.0.dylib              	0x000000010bfef144 gtk_window_show + 132
15  libgobject-2.0.0.dylib        	0x00000001075e3c60 g_cclosure_marshal_VOID__VOID + 224
16  libgobject-2.0.0.dylib        	0x00000001075e0685 g_type_class_meta_marshal + 117
17  libgobject-2.0.0.dylib        	0x00000001075dfba9 g_closure_invoke + 505
18  libgobject-2.0.0.dylib        	0x00000001076003b3 signal_emit_unlocked_R + 675
19  libgobject-2.0.0.dylib        	0x0000000107602274 g_signal_emit_valist + 5492
20  libgobject-2.0.0.dylib        	0x0000000107602bc4 g_signal_emit + 356
Comment 25 John Ralls 2018-07-02 17:44:14 UTC
Christoph, how are you testing the CSS font sizes and determining that they're "wrong"?

That stack trace has nothing at all to do with drawing text.
Comment 26 Tom Schoonjans 2018-07-20 11:22:08 UTC
I am adding some screenshots here to demonstrate the impact of the pango 1.42.2 release on macOS.

good.png: pango 1.42.1 and gtk 3.22.30
bad.png: pango 1.42.2 and gtk 3.22.30
ugly.png: pango 1.42.2 and gtk 3.22.30 patched with John's [PATCH] [Quartz] Hardcode screen resolution for text at 96.0.

These were made on a Retina 5K 27-inch iMac FWIW. There's definitely some work to be done here to get back to the situation shown in good.png...
Comment 27 Tom Schoonjans 2018-07-20 11:23:49 UTC
Created attachment 373103 [details]
pango 1.42.1 and gtk 3.22.30
Comment 28 Tom Schoonjans 2018-07-20 11:24:39 UTC
Created attachment 373104 [details]
pango 1.42.2 and gtk 3.22.30
Comment 29 Tom Schoonjans 2018-07-20 11:25:14 UTC
Created attachment 373105 [details]
pango 1.42.2 and gtk 3.22.30 patched with John's [PATCH] [Quartz] Hardcode screen resolution for text at 96.0.
Comment 30 Christoph Reiter (lazka) 2018-07-20 11:34:45 UTC
(In reply to John Ralls from comment #25)
> Christoph, how are you testing the CSS font sizes and determining that
> they're "wrong"?

If I apply some css to widgets, for example "min-height: 1.8rem", the height is larger than what it used to be, and what it is compared to the font size on win32/linux.
Comment 31 John Ralls 2018-07-20 14:15:38 UTC
Tom's attachments to my eye are, in order, font is too small, too big, and about right.

Christoph, min-height applies to the size of the box, not the font. Do you mean that the CSS code is getting the wrong font size so that the box isn't 1.8x the root element's font? (*not necessarily* the font inside the box!)? If the font resolution is set to 72 does it look right?

Perhaps some illustrations would be helpful.

The HiDPI handling on Windows is missing except in master so I'm not surprised that it looks different. Emmanuel Bassi gave a detailed explanation of HiDPI on Linux in gtk-devel a couple of years ago; my takeaway from that was that it works more or less the same as Mac: If the screen resolution is larger than some x dpi the Cairo code doubles the pixels used for everything. Are you testing on the same size & resolution (I guess ideally the same) monitor?
Comment 32 Tom Schoonjans 2018-07-20 14:23:04 UTC
Well to my eye the first attachment, representing how things have been for many years until pango 1.42.2 came out yesterday, has the right font. It also comes really close to what all other software on my Mac renders.

I am attaching another screenshot to demonstrate this.
Comment 33 Tom Schoonjans 2018-07-20 14:25:10 UTC
Created attachment 373110 [details]
Screenshot of gtk3-widget-factory, bibdesk and pages
Comment 34 John Ralls 2018-07-20 14:42:45 UTC
OK, then, the same question as I asked Christoph: If you change the scaling from 828f634 from 96 to 72 is it "right"?
Comment 35 Christoph Reiter (lazka) 2018-07-20 14:50:49 UTC
(In reply to John Ralls from comment #31)
> Tom's attachments to my eye are, in order, font is too small, too big, and
> about right.
> 
> Christoph, min-height applies to the size of the box, not the font. Do you
> mean that the CSS code is getting the wrong font size so that the box isn't
> 1.8x the root element's font? (*not necessarily* the font inside the box!)?
> If the font resolution is set to 72 does it look right?

yes, the box height isn't 1.8x of the font size like it was with previous versions of gtk/pango and on currently is on linux/win32.

I'll give that a try. How do I set it to 72?

> Perhaps some illustrations would be helpful.
> 
> The HiDPI handling on Windows is missing except in master so I'm not
> surprised that it looks different.

hidpi on Windows seems to work fine here. At least if I force enable it.

> Emmanuel Bassi gave a detailed
> explanation of HiDPI on Linux in gtk-devel a couple of years ago; my
> takeaway from that was that it works more or less the same as Mac: If the
> screen resolution is larger than some x dpi the Cairo code doubles the
> pixels used for everything. Are you testing on the same size & resolution (I
> guess ideally the same) monitor?

Same monitor, same resolution, but under virtual box.
Comment 36 Christoph Reiter (lazka) 2018-07-20 14:52:14 UTC
(In reply to Christoph Reiter (lazka) from comment #35)
> (In reply to John Ralls from comment #31)
> > Tom's attachments to my eye are, in order, font is too small, too big, and
> > about right.
> > 
> > Christoph, min-height applies to the size of the box, not the font. Do you
> > mean that the CSS code is getting the wrong font size so that the box isn't
> > 1.8x the root element's font? (*not necessarily* the font inside the box!)?
> > If the font resolution is set to 72 does it look right?
> 
> yes, the box height isn't 1.8x of the font size like it was with previous
> versions of gtk/pango and on currently is on linux/win32.
> 
> I'll give that a try. How do I set it to 72?

oh, you mentioned it below. I'll give that a try, once I figure out why things crash for me.
Comment 37 Tom Schoonjans 2018-07-23 07:22:16 UTC
I changed the scaling in 828f634 from 96 to 72 and now everything looks fine again...
Comment 38 Friedrich Beckmann 2018-11-13 09:54:00 UTC
Created attachment 374148 [details]
gtk3-demo on MacBookPro Retina with gtk3.22.30 patched (with Johns patch) and pango 1.42.4

I have a font scaling problem with the pspp application that I build on with Macports with gtk 3.22.30 with the quartz backend and pango 1.42.4. The discussion is here:

https://github.com/macports/macports-ports/pull/2989

Homebrew reverted a font scaling patch in pango to resolve the problem. When I do the same, then the result looks o.k.  to me. If have used pango 1.42.4 together with gtk 3.22.30, then the results looks really bad with much too large fonts.

When I apply Johns patch 

https://github.com/GNOME/gtk/commit/828f634d5c08b9c39626dd1512ec7a1af4800f3d

which is in gtk 3.22 upstream branch but not released together with pango 1.42.4, then the result looks as uploaded on my MacBookPro Retina. The fonts are still too large compared to the other applications.

When I start with GTK_DEBUG=interactive I can see that the gtk-font-name derived from quartz is ".AppleSystemUIFont 12". When I change that to size 10, it looks better. So I am not sure if the base font selection with size 12 is too large of if the font rendering is not correct.

However the resulting UI uses too large fonts.
Comment 39 Friedrich Beckmann 2018-11-13 10:10:19 UTC
Created attachment 374149 [details]
gtk3-demo on MacBookPro Retina with gtk3.22.30 patched (with Johns patch) and pango 1.42.4 with system font size 10

gtk3-demo with the gtk-font-name changed to size 10 via GTK_DEBUG=interactive and the gtk3 3.22.30 with Johns patch and pango 1.42.4.
Comment 40 John Ralls 2018-11-13 12:42:54 UTC
I agree that the current situation results in fonts being scaled larger in Gtk applications built with pango >= 1.42.2 and gtk >= 3-24.0. In fact they scale 96/72 (4/3) too big, which leads me to think that Behdad misunderstood what the Apple guys were telling him. After more study of the NSView documentation it seems to me that there's more than one scaling factor at play and the Quartz is doing more behind our backs than we realize.

If you change the value of dpi in gdkscreen-quartz.c line 72 from 96.0 to 72.0 does that make it more pleasing?
Comment 41 Behdad Esfahbod 2018-11-13 13:58:26 UTC
All I'm saying is, CoreText points are 96 an inch.  That's all I have opinion on in this issue.  And I don't doubt that.
Comment 42 Friedrich Beckmann 2018-11-13 21:27:00 UTC
Created attachment 374151 [details]
gtk3-demo on MacBookPro Retina with gtk3.22.30 patched (with Johns patch) changed to 72dpi and pango 1.42.4 - perfekt result

As John proposed I changed the dpi setting from 96 to 72 in Johns patch. The resulting window looks perfekt. The finder window which is left of the gtk3-demo window has a font size of 12. So now the font size 12 in the gtk3-demo window is the same size as in the MacOS Windows. My change (here in the macports patch file) is:

https://github.com/fredowski/macports-ports/commit/f6c0690bc3e5e70c28ee519fe586fabfdd8197eb

It would be very nice if this fix would end up in a 3.22.31 release...
Comment 43 John Ralls 2018-11-14 00:08:09 UTC
Gtk only maintains one branch for each major version, so I doubt that there will be any more gtk-3-22 releases. The current branch for gtk3 is gtk-3-24 and the last release was gtk-3.24.1.

I've pushed that change to gtk-3-24 so it should be in gtk-3.24.2.
Comment 44 Friedrich Beckmann 2018-11-14 06:10:16 UTC
Thanks!

So with this commit it will be fixed in 3.24.2

https://github.com/GNOME/gtk/commit/bb376222c104aef0ec7e31b40959bc35eecf2253