Opened 5 years ago
Last modified 4 years ago
#18376 needinfo defect
HiDPI font problems with 3840x2160 screen (Linux)
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Core | Version: | |
| Keywords: | template_report hidpi linux | Cc: |
Description (last modified by )
What steps will reproduce the problem?
- Run josm using a 15" 3840x2160 screen
- Notice that default fonts are small on a hires (290 DPI) screen
- Select larger fonts, where 18px is a minimum
What is the expected result?
That JOSM looks ok, using the bigger fonts properly. In particular, line to line distance should adjust to the big default font, and NOT assume that 14 px or so is "enough for everybody".
What happens instead?
I get the big font I ask for. Some widgets, like the menu, are ok. But some apparently uses hardcoded interline distances, and breaks with 18-30px fonts. In the attatched image, you can see several lines where only the upper half of the text shows. The lower half is overwritten by the next line, because the widgets don't use an interline distance large enough for the font selected. This is a bug.
Some of the icons are also very small on a 290DPI screen. That is not really a bug, although a selection of larger icons is a wishlist item.
Note that HiDPI screens is not the only case where a 20-30px font is used as default font for everything. People with weak eyes do this on cheaper displays too. Such people also need big fonts to work everywhere.
Please provide any additional information below. Attach a screenshot if possible.
Relative:URL: ^/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2019-11-01 23:59:01 +0100 (Fri, 01 Nov 2019) Revision:15492 Build-Date:2019-11-01 22:59:57 URL:https://josm.openstreetmap.de/svn/trunk Identification: JOSM/1.5 (15492 nb) Linux Artix Linux Memory Usage: 1596 MB / 7958 MB (934 MB allocated, but free) Java version: 11.0.5+10, Oracle Corporation, OpenJDK 64-Bit Server VM Screen: :0.0 3840x2160 Maximum Screen Size: 3840x2160 VM arguments: [-Djosm.restart=true] Program arguments: [2019-11-18_18-13-06.gpx] Dataset consistency test: No problems found Last errors/warnings: - W: No configuration settings found. Using hardcoded default values for all pools. - E: org.openstreetmap.josm.gui.oauth.OsmOAuthAuthorizationException: Failed to authorize OAuth request 'GJmnW1fXHhjviTU6pXmTO1qH62Z8IJFseRQDTzGq' - E: OAuth authorization failed - <html>The automatic process for retrieving an OAuth Access Token<br>from the OSM server failed.<br><br>Please try again or choose another kind of authorization process,<br>i.e. semi-automatic or manual authorization.</html> - E: org.openstreetmap.josm.gui.oauth.OsmOAuthAuthorizationException: Failed to authorize OAuth request 'S2UKMp2SEqqVkfbTud88Hi7WcYpUq7oPnWvELZfA' - E: OAuth authorization failed - <html>The automatic process for retrieving an OAuth Access Token<br>from the OSM server failed.<br><br>Please try again or choose another kind of authorization process,<br>i.e. semi-automatic or manual authorization.</html> - E: org.openstreetmap.josm.gui.oauth.OsmOAuthAuthorizationException: Failed to authorize OAuth request '7Hnl70SaLQG6gD3iqjFJFeSj9YDOrKsBvpLDN0rr' - E: OAuth authorization failed - <html>The automatic process for retrieving an OAuth Access Token<br>from the OSM server failed.<br><br>Please try again or choose another kind of authorization process,<br>i.e. semi-automatic or manual authorization.</html> - W: Region [WMS_BLOCK_v2] Resetting cache - W: Region [WMTS_BLOCK_v2] Resetting cache
Attachments (3)
Change History (24)
by , 5 years ago
comment:1 by , 5 years ago
| Keywords: | hidpi linux added |
|---|
by , 5 years ago
comment:2 by , 5 years ago
| Description: | modified (diff) |
|---|
comment:3 by , 4 years ago
@helge.hafting There is quite good HiDPI support in JOSM, based on the system-wide "screen scaling". I'm not sure how to configure this / whether you have configured this in your Linux desktop environment.
Having that configured, everything should scale, and increasing the font size should not be necessary.
Can you please send us an updated Status Report from the latest JOSM version? We have added more information for debugging problems in this area, recently.
comment:4 by , 4 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → needinfo |
comment:5 by , 4 years ago
I also have this issue. I use Ubuntu 20.04. Two screens scaled with fractional scaling in system settings; 4K (150% scaling) 1080p (100% scaling). In JOSM menu scaling is set to 2.0 and menu font scaling set to 1.0 in the expert options. Funnily enough I am also Norwegian, but that surely can't the problem XD
by , 4 years ago
| Attachment: | Skjermbilde fra 2020-07-31 20-18-08.png added |
|---|
I don't have the issue in layer listing but it's present other places
comment:6 by , 4 years ago
Sorry for the many posts. Noticed that OP hasn't given updated status report. Here is mine; https://paste.ubuntu.com/p/vDKHbfYXZv/
Relative:URL: ^/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2020-07-29 21:19:58 +0200 (Wed, 29 Jul 2020) Revision:16811 Build-Date:2020-07-30 01:30:51 URL:https://josm.openstreetmap.de/svn/trunk Identification: JOSM/1.5 (16811 nb) Linux Ubuntu 20.04.1 LTS Memory Usage: 407 MB / 4006 MB (231 MB allocated, but free) Java version: 14.0.2+12-46, Oracle Corporation, OpenJDK 64-Bit Server VM Look and Feel: com.sun.java.swing.plaf.gtk.GTKLookAndFeel Screen: :0.0 5120x2880 (scaling 1.0x1.0), :0.1 3840x2160 (scaling 1.0x1.0) Maximum Screen Size: 5120x2880 Best cursor sizes: 16x16 -> 16x16, 32x32 -> 32x32 Java ATK Wrapper package: libatk-wrapper-java:all-0.37.1-1 fonts-noto: fonts-noto:- VM arguments: [-Djosm.restart=true, -Djosm.dir.name=JOSM-latest, -Djava.net.useSystemProxies=true] Dataset consistency test: No problems found … gui.geometry=x=2495,y=44,width=1000,height=740 gui.maximized=true gui.scale=2.0 …
comment:7 by , 4 years ago
The status report shows "scaling 1.0x1.0" for both screens, which is unexpected.
"Ubuntu" does not tell us what window manager you use. Gnome? KDE? Something else even?
What happens if you set all JOSM scaling values to 1.0? Dimensions are consistent, but just everything is very small?
comment:8 by , 4 years ago
I use default Ubuntu 20.04 setup; Gnome. Everything looks fine on scaling 1.0 in JOSM with all text visible and not cut off, just everything is very small, yeah. The cut-off text is also a problem without fractional scaling. Now I have both my monitors at 100% scaling in system settings because of issues with games, and the cut-off text is still an issue with both gui scaling and gui.font scaling at 2.0.
follow-ups: 11 16 comment:9 by , 4 years ago
artix linux, wayland. josm 16812, 2020-07-31
With font size 12:
GDK_SCALE=1 josm
Nothing wrong, but very small.
GDK_SCALE=2 josm
Everything is fine. Useable font size and no drawing errors. I consider GDK_SCALE a hack though. Ideally, specify font size in some absolute size (cm, inches, points, ... - NOT pixels)
GDK_SCALE is a hack, for what to do as even higher resolutions become available? Scale to 3 or 4, so that a "12 pixel font" works? In a not so distant future when nobody uses a font that really is 12 pixels tall? A relic from a time where 12 pixels were nicely readable?
Wayland knows that my particular screen is 15", and the resolution is known too. I am not sure how much X11 knows, but X11 has a dpi setting, and it can be set to 290 which is correct for this display. So specifying an absolute font size should work in either case.
GDK_SCALE=3 josm
A bit too big, but everything works. Josm can use a 36-pixel font this way, without drawing errors.
With font size 24:
Correct size font even with GDK_SCALE=1. But the text gets cut off in many dialogs.
Strangely, josm can display a 24 pixel font if I call it a 12 pixel font, and have scaled to twice the size. But it cannot simply use a 24 pixel font specified as such.
GDK_SCALE does not matter for the problem. The pixel size is the problem. Somewhere in the code (or a library) is the assumption that nobody would use a 24-pixel font. But a large font is useful - the pixels may be small, or the user may need very large text to compensate for weak eyesight.
follow-ups: 18 19 comment:11 by , 4 years ago
Replying to 7rst1:
with both gui scaling and gui.font scaling at 2.0.
Where do you set "gui.font scaling at 2.0"?
Replying to helge.hafting@…:
With font size 12:
With font size 24:
Where do you specify the font size?
My summary so far would be that HiDPI is working unless one starts to modify the font sizes (somewhere).
comment:12 by , 4 years ago
Where do you set "gui.font scaling at 2.0"?
I'm not at home, so I can't check it. I might have written wrong key name in the comment you're referring to. If you search scale in advanced settings, it's the gui scaling one and another similar one with font in the name.
follow-up: 15 comment:13 by , 4 years ago
We have gui.scale, and for the menu font gui.scale.menu.font (it should not affect other fonts, though).
comment:14 by , 4 years ago
| Summary: | Widget/font problems with 3840x2160 screen → HiDPI font problems with 3840x2160 screen (Linux) |
|---|
comment:15 by , 4 years ago
Replying to simon04:
We have
gui.scale, and for the menu fontgui.scale.menu.font(it should not affect other fonts, though).
Yeah that one. I didn't check if it affected the issue so it most definitely doesn't, as you write.
follow-up: 20 comment:16 by , 4 years ago
Replying to helge.hafting@…:
Font sizes are measured in typographic points https://en.wikipedia.org/wiki/Point_(typography) not in pixels. That's why it makes a lot of sense to stay with 12pt fonts, as they indicate a real-world size (relating to the readability for a human eye from a normal distance). The actual technical size in pixels is then determined by the scaling factor.
For a better support for HiDPI displays, we have to get away from thinking in pixels. And setting to GDK_SCALE to 3 or 4 is the perfect solution indeed, for future displays with an even higher resolution.
See also "device pixel ratio" https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio
comment:17 by , 4 years ago
comment:18 by , 4 years ago
Replying to simon04:
Replying to 7rst1:
with both gui scaling and gui.font scaling at 2.0.
Where do you set "gui.font scaling at 2.0"?
Replying to helge.hafting@…:
With font size 12:
With font size 24:
Where do you specify the font size?
Sorry that I didn't specify that. It took me some time to find a way to change font size in josm - josm's own settings does not seem to have a working font selection. The font is changed in the file
/etc/gtk-3.0/settings.ini
The relevant line defaults to:
gtk-font-name = Cantarell 12
which some gtk-based programs uses. I can only guess that the purpose is to let users change to any font they prefer – a different typeface or a different size.
That size looks fine on a full-hd screen, but way too small on a HiDPI display. So I changed this line to:
gtk-font-name = Cantarell 24
I then get a nice font size in josm, and a few other programs that also uses that setting. Most text in josm is then fine, the splash screen is readable, buttons and the menu is nice and readable. But some windows, like the property dialog, seems to clamp the interline distance so the size-24 font get clipped.
My summary so far would be that HiDPI is working unless one starts to modify the font sizes (somewhere).
If josm is not meant to work with other font sizes, then there is another bug here. Josm uses the font from settings.ini – it shouldn't, if it is meant to use 12 pixels only. It is necessary to change settings.ini for the benefit of various other programs that uses this text size to good effect.
But it seems more reasonable that josm uses the font specification from settings.ini because it is meant to be flexible? Let the user specify whatever font fits their eyes or their display system? In that case, the clipping is a bug. Not necessarily a josm bug, it could be a toolkit bug. Only a developer could know that, so I report to josm because it is in josm I see a problem.
comment:19 by , 4 years ago
Replying to simon04:
Replying to 7rst1:
with both gui scaling and gui.font scaling at 2.0.
Where do you set "gui.font scaling at 2.0"?
Replying to helge.hafting@…:
With font size 12:
With font size 24:
Where do you specify the font size?
Sorry that I didn't specify that. It took me some time to find a way to change font size in josm - josm's own settings does not seem to have a working font selection. The font is changed in the file
/etc/gtk-3.0/settings.ini
The relevant line defaults to:
gtk-font-name = Cantarell 12
which some gtk-based programs uses. I can only guess that the purpose is to let users change to any font they prefer – a different typeface or a different size.
That size looks fine on a full-hd screen, but way too small on a HiDPI display. So I changed this line to:
gtk-font-name = Cantarell 24
I then get a nice font size in josm, and a few other programs that also uses that setting. Most text in josm is then fine, the splash screen is readable, buttons and the menu is nice and readable. But some windows, like the property dialog, seems to clamp the interline distance so the size-24 font get clipped.
My summary so far would be that HiDPI is working unless one starts to modify the font sizes (somewhere).
If josm is not meant to work with other font sizes, then there is another bug here. Josm uses the font from settings.ini – it shouldn't, if it is meant to use 12 pixels only. It is necessary to change settings.ini for the benefit of various other programs that uses this text size to good effect.
But it seems more reasonable that josm uses the font specification from settings.ini because it is meant to be flexible? Let the user specify whatever font fits their eyes or their display system? In that case, the clipping is a bug. Not necessarily a josm bug, it could be a toolkit bug. Only a developer could know that, so I report to josm because it is in josm I see a problem.
comment:20 by , 4 years ago
Replying to johsin18:
Replying to helge.hafting@…:
Font sizes are measured in typographic points https://en.wikipedia.org/wiki/Point_(typography) not in pixels. That's why it makes a lot of sense to stay with 12pt fonts, as they indicate a real-world size
If it is 12 points (and not 12 pixels), then I agree. But then the software ought to display nice readable 12 point text on my screen. This is not happening, therefore a bug report. I just assumed the size was in pixels, precisely because the real size seems to vary with the display pixel size. The smaller pixels a screen has, the smaller this size 12 font looks. Unlike printing, where I get the same size no matter if I have a 300dpi or a 1200dpi printer.
(relating to the readability for a human eye from a normal distance). The actual technical size in pixels is then determined by the scaling factor.
For a better support for HiDPI displays, we have to get away from thinking in pixels. And setting to GDK_SCALE to 3 or 4 is the perfect solution indeed, for future displays with an even higher resolution.
No way. As I said, GDK_SCALE is a hack. Having to adjust scale forever - no thanks. "displays used to be 96 dpi or so, when GUIs became mainstream" - therefore we have to specify fonts for an ancient 96 dpi display nobody is using and a scaling factor to make it work with today's displays?
No, the reasonable way is to specify an absolute size like "12 pt" and have that come out as 12 pt on whatever screen it is displayed on. (12pt measurable with a ruler held in front of the screen) The OS knows the pixel pitches of every display connected to my computer. (And if that isn't always the case, let the user specify display DPI in OS settings. No need for laptop displays or HDMI/VGA displays – they all report their true DPI to the OS.)
See also "device pixel ratio" https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio
Yes, something like that. Except for wayland/x/windows, instead of web.
Unfortunately, we aren't there yet. gtk specifies a font size of "12" without units. And it looks smaller on higher resolution displays, so clearly it is a pixel size and not a point size. Currently, josm just uses that.
Josm have the option of querying the OS for display resolution, and offer a config option with a font size in points, cm, inches or whatever. That might be a lot of work and therefore take a long time. It'd nice if a size 24 font (or whatever one might want) would just work though.
comment:21 by , 4 years ago
The issue completely disappears when I switched from Xorg to Wayland and using its fractional scaling instead. However, Wayland is the window server Helge has been using all the time while experiencing this issue right? Weird... Everything here now looks perfect.
File is a screenshot (From a 15" 290DPI laptop screen), showing widgets rendering lines too tight. Please do not assume a fixed number of pixels is "enough"; instead use the height of the font being used!