Text font is tiny on a HiDPI screen

[sebastic]

As reported by @vinc17fr in Debian Bug #1109594:

I've just tried gpsprune, and the text font is tiny (thus text is very hard to read) on a HiDPI screen.

I don't know whether there is a way to configure it, but

• A readable size should be the default.
• If a configuration is needed, one must be able to do it without via a tiny font size.

Changing the display options to GTK makes it a bit better, but this is still too small compared to the usual GTK applications.

[vinc17fr]

As found in #16, GDK_SCALE=2 makes the text readable. But this does not explain why it is needed for gpsprune only.

[vinc17fr]

This may be a more general Java issue, as GeoGebra (also a Java application) looks the same. BTW, though GDK_SCALE=2 makes the text readable, the font rendering is ugly (in both GeoGebra and GpsPrune), with some lines thicker than others.

[vinc17fr]

With GDK_SCALE=2:

• Windows can be too large for the screen and/or appear partly off-screen (this affects only GpsPrune).
• After the main window is resized, the menu handling gets completely broken, making the application unusable (this affects both GpsPrune and GeoGebra).

[pykereaper]

I can confirm that GpsPrune is not usable on HiDPI screens:

[activityworkshop]

The configuration of systems with hidpi screens is complex, as can be seen in the discussions of Issues #16, #19 and #50, among others.

It depends on your hardware, obviously, but also on your operating system (I assume @vinc17fr uses Debian, I don't know what @pykereaper has), your desktop or window manager and how that's configured, and your java configuration. The settings provided by GpsPrune are in addition to all of those and work in combination.

What GpsPrune offers is under Settings -> Set display options, which control the OS-scaling of map images and the sizing of GpsPrune's icons. Options for default ("readable") text sizes will be on the java level or the system level.

I don't agree with the flat statement that "GpsPrune is not usable", I think it depends on a lot of configuration choices. All your screenshot shows is that (with your current configuration) the fonts used by java are shown smaller than the fonts used by your browser. I can't judge whether that makes it unusable for you or not, but the output looks correct.

Oh, and about fonts being "too small compared to the usual GTK applications", be aware that GpsPrune isn't a GTK application. It's a java application which you have configured to use a "GTK-like" style, but that doesn't mean it uses GTK or its configuration.

I'm not sure if you have multiple screens with different dpi values or not - having such a system obviously makes configuration more challenging.

[vinc17fr]

Yes, I use Debian.

I've eventually found https://wiki.archlinux.org/title/HiDPI but in any case, neither GDK_SCALE=2 nor -Dsun.java2d.uiScale=2 is satisfactory as the value must be an integer, and 2 is already too big. And such scaling produces low-quality output. This may be a general java issue, but that would be surprising if applications cannot control the font size as a workaround.

[pykereaper]

Thanks for the feedback @activityworkshop . I fully agree: HiDPI is complex and the different behavior on different operating systems is tedious.

My system:

• Ubuntu 24.04
• Internal display: 14" 3.840 x 2.160 (Screen scale: 200%)
• External display: 24" WQHD (Screen scale: 100%)
• Desktop environment: GNOME 46.0
• Window manager: Mutter/Wayland

My screenshot is intended to show that GPSPrune indeed is half the size than regular text, as it simply doesn't automatically adapt to the 200% scale setting of GNOME. And that is way too small to e.g. be able to navigate into the app settings.

The problem with users having to manually set environment variables like GDK_SCALE or other things is: Not every user is aware of that. And further: It can be extremely cumbersome, if one is using different screens. As stated, I have set 200% scale for my laptop screen, when working on the go. But at home I use a WQHD external display with 100% scale factor. Basically every app adapts to this setting and I can just open and use all my tools, no matter what display I am using.

I do have some JavaFX applications, which target at least SDK 17. From this version on, it is fully compatible with the scale settings of my environment:

HiDPI scaling fixed for linux platforms

Swing developers on the other hand seem to not really being interested in this topic. So besides re-writing everything for JavaFX, one could maybe try something like I did some time ago on a JavaFX (<17) application:

/**
 * Needed for retina displays:
 * multiplication factor for e.g. text to be readable.
 */
val scaleFactor = Screen.getPrimary().dpi / 96.0  // 96 dpi == default

/**
 * Traverse the entire layout, check where a text is present and
 * multiply the text size with the displays scale factor.
 */
private fun Pane.changeAllFontSizes() {
    this.children.forEach {
        when (it) {
            // change text size
            is Labeled -> it.font = Font(it.font.name, it.font.size * scaleFactor)
            is TextInputControl -> it.font = Font(it.font.name, it.font.size * scaleFactor)
            // traverse
            is Pane -> it.changeAllFontSizes()
        }
    }
}

[vinc17fr]

In my case, I'm under X11.

The problem with users having to manually set environment variables like GDK_SCALE or other things is: Not every user is aware of that.

Yes, and in particular, I have never needed to use this environment variable with the other applications.

And further: It can be extremely cumbersome, if one is using different screens. As stated, I have set 200% scale for my laptop screen, when working on the go. But at home I use a WQHD external display with 100% scale factor. Basically every app adapts to this setting and I can just open and use all my tools, no matter what display I am using.

Similarly, I also still use different screens (4K and WQHD), and my init script detects the kind of screen automatically, so that the settings can be adapted automatically, but without using a scale factor (well, actually, Xft.dpi is set to 132 with my 4K screens and 88 with my WQHD screen). But with my WQHD screen, I use bitmap fonts in text terminals so that small fonts look better.

[pykereaper]

I don't agree with the flat statement that "GpsPrune is not usable", I think it depends on a lot of configuration choices. All your screenshot shows is that (with your current configuration) the fonts used by java are shown smaller than the fonts used by your browser. I can't judge whether that makes it unusable for you or not, but the output looks correct.

Little clarification on the usability of GPSPrune in my screenshot. As I mentioned, this screenshot was done while I was using my internal screen on 200% scale. Hence, to compare the size of the text on your regular "100%" screen one just had to scale the screenshot down to 50%. This is how it looks:

(Use right-click | Open Image in New Tab)

[activityworkshop]

I'm still missing a clear suggestion of what GpsPrune can do about these hidpi issues, beyond what it already does. Maybe there's something that the OS can do, or wayland/X or the desktop/WM, or java.

Migrating to JavaFx is almost certainly not a possibility, due to the effort required to do the migration and the effort required by users to install JavaFx. Note that it's still tricky to persuade some users to migrate away from Java 8 runtimes.

I can see what you're doing with your changeAllFontSizes method, but you'd have to be careful to execute that only once, otherwise the fonts will get increasingly larger every time, right? And I would imagine that you'd run into problems if you start the application on one screen (with one dpi) and then drag it across to the other screen (with a different dpi).

One option would be to have a font scaling factor configurable inside GpsPrune (for labels, comboboxes, menu items, listboxes and so on), but it sounds like that should be unnecessary if other applications can do it automatically - in which case it's a question for Java, not for GpsPrune.

[pykereaper]

Yes, changeAllFontSizes certainly should only be executed once on application start. This of course means, that when a DPI setting is changed, the app won't resize. However, in my experience, this will seldom happen. See:

Regarding different DPI settings on different monitors: At least on Ubuntu with my configuration that is not possible. You can only set one global zoom level for all monitors. This sometimes can be annoying and only shows how complicated this matter is.

In case of a JavaFX migration, you would best provide a fat jar. But you would also have to consider that in order for the DPI scaling to work out of the box, you'd at least need Java 17, so that would eliminate the SDK 8 version.

[kwagnitz]

I've struck the same issue with a new hi-res laptop running Ubuntu 25.10 Wayland.
Text and menus are unreadable. Tried setting screen resolution to 1920x1080 or 200% in Ubuntu screen settings. Makes no difference to GPSPrune. But this is common to Java apps. Its the same for JOSM.
-Eclipse IDE however, looks fine.
This is a fundamental problem where Java apps don't use the screen settings provided by the OS screen manager.
I have no idea what the solution is, but one needs to be found that works for all Java apps. I don't think they all should need to have the ability to scale up built in to each app. (Doesn't seem to be an issue for apps under Windows.)

[pykereaper]

This is a fundamental problem where Java apps don't use the screen settings provided by the OS screen manager. I have no idea what the solution is, but one needs to be found that works for all Java apps.

That is not entirely true. Like I already described: It all comes down if the GUI framework supports HiDPI scaling.

• Newer versions of JavaFX fully support this.
• Same seems to be the case with SWT (based on your remark on Eclipse IDE).
• However, no such luck with Swing, which GpsPrune relies on.

[activityworkshop]

Correct, GpsPrune uses Swing, and isn't likely to switch to either JavaFX or SWT, at least not in the near future and not just because of some users' issues with tiny pixels.

On the development page there's a test jar which makes an attempt to scale the texts in the Swing GUI using a configurable text scaling factor (100% to 300%). Depending on your selected window style (and your other display settings) this may improve things, or it may potentially cause other rendering issues (for example checkboxes, radio buttons). If this proves to be helpful, it may come with GpsPrune version 27, but if it turns into an endless cycle of half-fixes then we'll have to wait until Java and Swing deliver something more robust.

Oh, and happy New Year!