GNOME Bugzilla – Bug 787867
OSX macports pango text size appears to vary between version 1.40.12 (bad) and 1.40.6 (good)
Last modified: 2018-11-14 06:10:16 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)
Looks like fallout from https://bugzilla.gnome.org/show_bug.cgi?id=782393
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?
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.
(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.
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).
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?
yes, just returning those 5 lines fixes my problem
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?
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?
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.
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...
So... A couple of releases have passed, just pinging to see if you forgotten about this issue.
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.
(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?
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.
*** Bug 795188 has been marked as a duplicate of this bug. ***
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.
Looks good to me, but that shouldn't mean much. :)
Anyone else want to weigh in?
Comment on attachment 371525 [details] [review] Restore 96ppi scaling Not having heard from anyone else, I've pushed the changes.
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.
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.
Thanks! I'll give that a try :)
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
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.
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...
Created attachment 373103 [details] pango 1.42.1 and gtk 3.22.30
Created attachment 373104 [details] pango 1.42.2 and gtk 3.22.30
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.
(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.
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?
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.
Created attachment 373110 [details] Screenshot of gtk3-widget-factory, bibdesk and pages
OK, then, the same question as I asked Christoph: If you change the scaling from 828f634 from 96 to 72 is it "right"?
(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.
(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.
I changed the scaling in 828f634 from 96 to 72 and now everything looks fine again...
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.
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.
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?
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.
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...
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.
Thanks! So with this commit it will be fixed in 3.24.2 https://github.com/GNOME/gtk/commit/bb376222c104aef0ec7e31b40959bc35eecf2253