Modify

Opened 4 years ago

Last modified 3 years ago

#18376 needinfo defect

HiDPI font problems with 3840x2160 screen (Linux)

Reported by: helge.hafting@… Owned by: helge.hafting@…
Priority: normal Milestone:
Component: Core Version:
Keywords: template_report hidpi linux Cc:

Description (last modified by Don-vip)

What steps will reproduce the problem?

  1. Run josm using a 15" 3840x2160 screen
  2. Notice that default fonts are small on a hires (290 DPI) screen
  3. 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)

josm2.png (2.6 MB ) - added by helge.hafting@… 4 years ago.
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!
18376.png (778.7 KB ) - added by Don-vip 4 years ago.
Skjermbilde fra 2020-07-31 20-18-08.png (789.0 KB ) - added by 7rst1 4 years ago.
I don't have the issue in layer listing but it's present other places

Change History (24)

by helge.hafting@…, 4 years ago

Attachment: josm2.png added

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!

comment:1 by Don-vip, 4 years ago

Keywords: hidpi linux added

by Don-vip, 4 years ago

Attachment: 18376.png added

comment:2 by Don-vip, 4 years ago

Description: modified (diff)

comment:3 by johsin18, 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 skyper, 4 years ago

Owner: changed from team to helge.hafting@…
Status: newneedinfo

comment:5 by 7rst1, 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 7rst1, 4 years ago

I don't have the issue in layer listing but it's present other places

comment:6 by 7rst1, 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
…
Last edited 4 years ago by simon04 (previous) (diff)

comment:7 by johsin18, 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 7rst1, 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.

comment:9 by helge.hafting@…, 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.

Last edited 4 years ago by simon04 (previous) (diff)

comment:10 by simon04, 4 years ago

In 16911/josm:

see #18376 - Status report: add Linux desktop environment

in reply to:  9 ; comment:11 by simon04, 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 7rst1, 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.

comment:13 by simon04, 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 simon04, 4 years ago

Summary: Widget/font problems with 3840x2160 screenHiDPI font problems with 3840x2160 screen (Linux)

in reply to:  13 comment:15 by 7rst1, 4 years ago

Replying to simon04:

We have gui.scale, and for the menu font gui.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.

in reply to:  9 ; comment:16 by johsin18, 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 simon04, 4 years ago

For a supported font size configuration within JOSM see #8334 and the recent changes r16960 and r16961.

in reply to:  11 comment:18 by anonymous, 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.

in reply to:  11 comment:19 by helge.hafting@…, 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.

in reply to:  16 comment:20 by helge.hafting@…, 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 7rst1, 3 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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as needinfo The owner will remain helge.hafting@….
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from helge.hafting@… to the specified user. Next status will be 'new'.
as duplicate The resolution will be set to duplicate. Next status will be 'closed'. The specified ticket will be cross-referenced with this ticket.
The owner will be changed from helge.hafting@… to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.