New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 403302 link

Starred by 18 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Mar 2015
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

issue 143619

Sign in to add a comment

UI font is too big when point-based font size is incorrect for the configured DPI

Reported by, Aug 13 2014

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2121.3 Safari/537.36

Steps to reproduce the problem:
1. Open Browser
2. See 2x too big text

What is the expected behavior?
Font size should be appropriate.

What went wrong?
Apologies if this is a duplicate, I have searched but I can't find anything similar.

The screenshot shows the issue quite clearly.

The screenshot was taken using --force-device-scale-factor=2 on a hidpi-capable laptop, however the issue is still present with that switch removed (font sizes are of course, smaller but still 2x too large for their container).

Before I took the screenshot I blew away the contents of ~/.config/google-chrome* to ensure it isn't something I configured.

Did this work before? Yes A while ago - this has been the case for several weeks now.

Chrome version: 38.0.2121.3  Channel: dev
OS Version: Fedora 20
Flash Version: Shockwave Flash 14.0 r0
Screenshot from 2014-08-13 13:21:40.png
174 KB View Download

Comment 1 by, Aug 14 2014

Labels: Cr-UI-HighDPI

Comment 2 by Deleted ...@, Aug 14 2014

I can confirm I get the same issue. I think it started since version 38.x.

Comment 3 by, Aug 20 2014

Still exists in 38.0.2125.0 dev (64-bit), except the tab labels are now vertically middle aligned (instead of top aligned as in the screenshot).

Comment 4 by, Oct 7 2014

Version 39.0.2171.7 dev (64-bit) is affected too.
Labels: Needs-Feedback
Unable to reproduce the issue for chrome version - 40.0.2188.2 on Fedora 20 OS. Font size looks correct. Could you please try a fresh installation clearing the .config file and update us with your observations. Attached a screen shot for the same.
Screenshot from 2014-10-16 13:08:46.png
74.5 KB View Download

Comment 6 Deleted

Comment 7 by, Oct 16 2014

Tried with the most recent 40 release and I'm still seeing the behaviour.

I created a new user account on the computer to ensure that it's not a GNOME setting I've changed.

I'll also try with with a livedvd tomorrow.

Comment 8 by, Oct 17 2014

OS: Fedora 20, 64-bit, not a HiDPI m/c
Chrome Version: 40.0.2188.2, 39.0.2171.27, 38.0.2125.104
Machine: Zereason UltraLap 440

Steps followed:
1. Launch Chrome with fresh install.

Chrome launched as in screenshot mentioned in #5. 

This is a HighDPI issue. In-house we do not have Linux HighDPI machines. If possible please confirm if this issue happens on non-HighDPI machine.

Comment 9 by, Oct 20 2014

Yes, this is a HighDPI machine - 3200 × 1800

I've not seen I've not seen this on non-HighDPI machines.

Comment 10 by, Oct 20 2014

I managed to get Chrome 40 installed on Fedora 20 Live - the font is also oversized on that.
Labels: fedora
Blocking: chromium:143619
Issue 465840 has been merged into this issue.
Status: Available

Comment 15 by, Mar 10 2015

I think my fixes this.

Comment 16 by, Mar 10 2015

Seeing the output from building and running on systems that are exhibiting this problem would be helpful.

Comment 17 by, Mar 10 2015

As attached. If you need dump_xsettings, just tell.

Comment 18 by, Mar 10 2015

Captcha ate it.
1.7 KB View Download

Comment 19 by, Mar 10 2015

Also Michael's fix really makes it better. Sure, the Apps bar might now have a teensy too small font, but the remainder looks sort of good on scale-factor=2. The default scale factor is just too small but the UI fonts and sizes don't look out of place.

Comment 20 by, Mar 10 2015

#17: Thanks. The "gtk-xft-dpi" GtkSettings property is 196608, which corresponds to 192 DPI. 192 DPI / 72 points-per-inch means that there should be 2.67 pixels per point. The default GTK font description is "Sans 9" (i.e. 9 points since there's no "px" suffix), so this seems like it should result in a font size of 9 * 2.67 = 24 pixels. Could you attach a screenshot of a Chrome window? Specifically, I think that this size is used for the tab and menu font.

I'm also curious whether configuring GTK to specify the UI font size in pixels rather than points (e.g. "Sans 12px") helps here.

Comment 21 by, Mar 10 2015

See for the screenshots. This is a 15.6" laptop with a 4k display.

Comment 22 by, Mar 10 2015

I also attach output of font-config-info together with a screenshot.
107 KB View Download
1.8 KB View Download

Comment 23 by, Mar 10 2015

Thanks. Based on the math in #20, it looks like Chrome is using the expected size to render a 9-point font at 192 DPI. I'd recommend trying to instead use a pixel-based size as described in #20. Alternately, you could try giving up on using a custom DPI setting and change the "gtk-xft-dpi" property to 98304 (for 96 DPI).

(As an aside, your display looks like it's actually around 282.42 DPI, given a 3840x2160 resolution. Correcting that will likely make the fonts even bigger, though.)

Comment 24 by, Mar 10 2015

Note that the UIs drawn by Gtk (Cinnamon and Unity) are actually drawn correctly. Everything is as big as I'd expect it out of the box. Hence modifying GtkSettings seems awkward.

Comment 25 by, Mar 10 2015

I change DPI settings to non-hidpi when connecting an external monitor (3K, 27 inch) which I often use instead of the one build in my laptop (3K, 14 inch). In such a normal mode everything looks OK, but you would need a magnifying glass too use a laptop's screen ;). I'd rather expect tabs, address bar, user switcher (on the right) to be rendered bigger, not fonts to be small enough to fit in these tiny areas.

Comment 26 by, Mar 10 2015

Summary: UI font is too big when point-based font size is incorrect for the configured DPI (was: UI font size much too large)
#22: Your configuration is identical to #18 (192 DPI, 9-point font).

I think that the main issue here is that X11 DPI settings are all over the board: they default to 96 DPI but are often set to other values (which may either be correct given the display's physical dimensions or too high or too low).

Fonts can be specified in either pixels (denoted by a "px" suffix in a Pango font description) or points (denoted by no suffix). There are 72 points in an inch, so if a font is specified in points, the pixel size at which is rendered is based on the display's DPI.

a)  Issue 375824  tracked a regression where the reported DPI wasn't used when computing the pixel sizes of point-based fonts, resulting in those fonts being excessively small on systems that used a custom DPI in conjunction with point-based sizes that were chosen properly for the DPI.

b) Correcting that exposes the problem reported here: If GTK requests a 9-point font and reports a 192-DPI display, the fonts are going to be 24 pixels. While this clearly isn't desirable behavior, the main issue seems to be that the DPI setting and configured font size are out of whack.

The fix for  issue 375824  can't be reverted without breaking things again for the configurations in a). If there's some other way to make things work for both groups of configurations, Chrome should do that. From comments here, maybe GTK is doing that already -- it'd be good to dig into its code to see how it computes font sizes when custom DPIs are set.

Comment 27 by, Mar 10 2015

I'll run font-config-info a try on my HiDPI machine tomorrow - I've not changed any DPI settings though, just used whatever Fedora 19 configured on installation.

Comment 28 by, Mar 10 2015

> b) Correcting that exposes the problem reported here: If GTK requests
> a 9-point font and reports a 192-DPI display, the fonts are going to
> be 24 pixels. While this clearly isn't desirable behavior, the main
> issue seems to be that the DPI setting and configured font size are
> out of whack.

What is wrong with those settings? 24 pixels is probably what user expects in this case. For me the problem is that tabs are too small for fonts. Is there some possibility to control size of tabs?

Comment 29 by, Mar 11 2015

Please star  issue 143619  to track the progress of general high-DPI support on Linux.

Comment 30 by, Mar 11 2015

font-config-info attached.
1.9 KB View Download

Comment 31 by, Mar 11 2015

I think the attached screenshot with Chrome running with Michael's patch to disable UI scaling, plus --force-device-scale-factor=2 is what I actually want to see when I load up Chrome on this device.
166 KB View Download

Comment 32 by, Mar 11 2015

An argument can be made that the notification bars still have a font that's slightly too large, but the result is already so much better. ;-)

Comment 33 by, Mar 15 2015

FYI: I’ve uploaded a new patch set at which further improves the rendering (crisper fonts) of the parts of the UI in question. In case you were using my previous patch set, you’ll probably want to upgrade :).

Comment 34 by, Mar 16 2015

New patch set still looks good to me. It's sad how bad the screenshot attached here renders because gnome-screenshot reduces to full HD. It's crisp in reality.

This still doesn't solve auto-detecting of scale-factor=2, though. ;-)

Comment 35 by, Mar 16 2015

The device scale factor is automatically detected to be 2 for me. Note that I did compile chromium with enable_hidpi=1 by changing build/common.gypi like so:

diff --git i/build/common.gypi w/build/common.gypi
index 515f50a..4827f51 100644
--- i/build/common.gypi
+++ w/build/common.gypi
@@ -211,7 +211,7 @@
           # Enable HiDPI on Mac OS, Chrome OS and Windows.
-          ['OS=="mac" or chromeos==1 or OS=="win"', {
+          ['OS=="mac" or chromeos==1 or OS=="win" or OS=="linux"', {
             'enable_hidpi%': 1,

(You need to run build/gyp_chromium afterwards.)

If this doesn’t do the trick for you, your DPI is most likely incorrectly configured on the X11 level. Try using `xrandr --dpi 192`, see also

Comment 36 by, Mar 20 2015

sadrul, I think this issue can be closed since has landed.
Status: Fixed

Fixed by (unfortuately trying to set Owner correctly throws an error about non-project memebers :/)

Sign in to add a comment