[patch] Font size in Note dialog is very small in Windows10

[vasony <vasony.tamas@…>]

What steps will reproduce the problem?

1. Download any area
2. Click the create note icon
3. Enter some text

What is the expected result?

Font size is the same as in the Tags/Membership dialog

What happens instead?

Font size is smaller.

Please provide any additional information below. Attach a screenshot if possible.

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2021-04-27 20:35:33 +0200 (Tue, 27 Apr 2021)
Build-Date:2021-04-27 21:58:39
Revision:17833
Relative:URL: ^/trunk

Identification: JOSM/1.5 (17833 en) Windows 10 64-Bit
OS Build number: Windows 10 Enterprise 1909 (18363)
Memory Usage: 517 MB / 1820 MB (271 MB allocated, but free)
Java version: 1.8.0_291-b10, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Look and Feel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Screen: \Display0 1920×1080 (scaling 1.00×1.00) \Display1 1920×1080 (scaling 1.00×1.00)
Maximum Screen Size: 1920×1080
Best cursor sizes: 16×16→32×32, 32×32→32×32
System property file.encoding: Cp1250
System property sun.jnu.encoding: Cp1250
Locale info: en_US
Numbers with default locale: 1234567890 -> 1234567890

Plugins:
+ AddrInterpolation (35640)
+ FixAddresses (35640)
+ Mapillary (1.5.37.6)
+ OpeningHoursEditor (35640)
+ apache-commons (35524)
+ apache-http (35589)
+ buildings_tools (35669)
+ imagery_offset_db (35640)
+ javafx-windows (35655)
+ jna (35662)
+ measurement (35640)
+ reverter (35732)
+ scripting (30798)
+ turnrestrictions (35640)
+ undelete (35640)
+ utilsplugin2 (35691)

Tried with Java Adopt OpenJDK16 as well, the result is the same.

[vasony <vasony.tamas@…>]

Screenshot

[anonymous]

Look and feels

[anonymous]

Please note that this bug only affects the "Windows" and "Windows Classic" themes. Font sizes are correct in Metal and CDE/Motif look and feel.

[gaben]

Ticket #22648 has been marked as a duplicate of this ticket.

[gaben]

In #22648 @mpasha reported same on Java 18, so the scaling problem probably persist across Java versions 8..18.

[gaben]

Also see #22253.

[gaben]

The following seems to fix both this and #22253.

src/org/openstreetmap/josm/gui/widgets/JosmTextArea.java

@@ -6 +6 @@
 import java.awt.event.FocusListener;
 
 import javax.swing.JTextArea;
+import javax.swing.UIManager;
 import javax.swing.text.Document;
 
 import org.openstreetmap.josm.gui.MainApplication;
@@ -90 +91 @@
      */
     public JosmTextArea(Document doc, String text, int rows, int columns) {
         super(doc, text, rows, columns);
+        setFont(UIManager.getFont("TextField.font"));
         launcher = TextContextualPopupMenu.enableMenuFor(this, true);
         addFocusListener(this);
     }

@taylor Could you please have a look? I checked both on Ubuntu with Java 11 (no change) and Windows with Java 8. The latter no longer produces small fonts.

[taylor.smock]

setFont(UIManager.getFont("TextField.font"));

As a stupid question, why not TextArea.font? With Java 20, they appear to be the same on Windows.

[taylor.smock]

NVM. I think this is a LaF issue.

See ​WindowsLookAndFeel.java#L1393 and ​WindowsLookAndFeel.java#L1401 versus ​MetalLookAndFeel.java#L698 and ​MetalLookAndFeel.java#L708.

I'll open an upstream ticket.

[taylor.smock]

Upstream ticket: ​https://bugs.openjdk.org/browse/JDK-6396936

I think we can just put it in PlatformHookWindows.

[taylor.smock]

@gaben: Can you check and see if the following works for you?

src/org/openstreetmap/josm/tools/PlatformHookWindows.java

@@ -70 +70 @@
 import java.util.regex.Matcher;
 import java.util.regex.Pattern;
 
+import com.sun.java.swing.plaf.windows.WindowsLookAndFeel;
 import org.openstreetmap.josm.data.Preferences;
 import org.openstreetmap.josm.data.StructUtils;
 import org.openstreetmap.josm.data.StructUtils.StructEntry;
@@ -79 +80 @@
 import org.openstreetmap.josm.io.OnlineResource;
 import org.openstreetmap.josm.spi.preferences.Config;
 
+import javax.swing.UIManager;
+
 /**
  * {@code PlatformHook} implementation for Microsoft Windows systems.
  * @since 1023
@@ -152 +155 @@
         extendFontconfig("fontconfig.properties.src");
     }
 
+    @Override
+    public void preStartupHook() {
+        // See #20850. The upstream bug (JDK-6396936) is unlikely to ever be fixed due to potential compatibility
+        // issues. This affects Windows LaF only (includes Windows Classic, a sub-LaF of Windows LaF).
+        if (UIManager.getLookAndFeel() instanceof WindowsLookAndFeel
+                && "Monospaced".equals(UIManager.getFont("TextArea.font").getFamily())) {
+            UIManager.put("TextArea.font", UIManager.getFont("TextField.font"));
+        }
+    }
+
     @Override
     public void startupHook(JavaExpirationCallback javaCallback, WebStartMigrationCallback webStartCallback) {
         warnSoonToBeUnsupportedJava(javaCallback);

[gaben]

Unfortunately, it's not working. Also, I couldn't compile it with Java 11 because the WindowsLookAndFeel class isn't available.

Furthermore, the UIManager.getLookAndFeel() returns javax.swing.plaf.metal.MetalLookAndFeel even on Windows with native LaF. Maybe the LafPreference should be used, but I haven't dug into it yet.

[taylor.smock]

I probably have to fiddle with the location of the patch; I thought that we were setting the LaF early in startup. I'll check the code flow.

But it does look like we have a MainApplication.applyWorkarounds method which would be an even better location to put it (it does LaF workarounds).

[taylor.smock]

src/org/openstreetmap/josm/gui/MainApplication.java

@@ -1101 +1101 @@
         if ("Metal".equals(laf) && javaVersion >= 11 && javaVersion < 17) {
             UIManager.put("ToolTipUI", JosmMetalToolTipUI.class.getCanonicalName());
         }
+
+        // See #20850. The upstream bug (JDK-6396936) is unlikely to ever be fixed due to potential compatibility
+        // issues. This affects Windows LaF only (includes Windows Classic, a sub-LaF of Windows LaF).
+        if ("Windows".equals(laf) && "Monospaced".equals(UIManager.getFont("TextArea.font").getFamily())) {
+            UIManager.put("TextArea.font", UIManager.getFont("TextField.font"));
+        }
     }
 
     static void setupCallbacks() {

[gaben]

Yeah, yesterday I fiddled a bit around the applyWorkarounds() method but could not get it work.

Negative :( The patch in comment:16 doesn't work.

[taylor.smock]

Looks like I'm going to have to use windows for debugging. Hopefully no one else needs to use that system while I'm doing that.

[anonymous]

This should work (taylor.smock here; not logged in on Windows machine).

src/org/openstreetmap/josm/gui/MainApplication.java

@@ -841 +841 @@
 
         PlatformManager.getPlatform().afterPrefStartupHook();
 
-        applyWorkarounds();
-
         FontsManager.initialize();
 
         GuiHelper.setupLanguageFonts();
@@ -913 +911 @@
         }
         // Configure Look and feel before showing SplashScreen (#19290)
         setupUIManager();
+        // Then apply LaF workarounds
+        applyLaFWorkarounds();
         // MainFrame created before setting look and feel and not updated (#20771)
         SwingUtilities.updateComponentTreeUI(mainFrame);
 
@@ -1062 +1062 @@
                 JOSM_WEBSITE_NTV2_SOURCE);
     }
 
-    static void applyWorkarounds() {
+    /**
+     * Apply workarounds for LaF and platform specific issues. This must be called <i>after</i> the
+     * LaF is set.
+     */
+    static void applyLaFWorkarounds() {
         final String laf = UIManager.getLookAndFeel().getID();
         final int javaVersion = Utils.getJavaVersion();
         // Workaround for JDK-8180379: crash on Windows 10 1703 with Windows L&F and java < 8u141 / 9+172
@@ -1101 +1105 @@
         if ("Metal".equals(laf) && javaVersion >= 11 && javaVersion < 17) {
             UIManager.put("ToolTipUI", JosmMetalToolTipUI.class.getCanonicalName());
         }
+
+        // See #20850. The upstream bug (JDK-6396936) is unlikely to ever be fixed due to potential compatibility
+        // issues. This affects Windows LaF only (includes Windows Classic, a sub-LaF of Windows LaF).
+        if ("Windows".equals(laf) && "Monospaced".equals(UIManager.getFont("TextArea.font").getFamily())) {
+            UIManager.put("TextArea.font", UIManager.getFont("TextField.font"));
+        }
     }
 
     static void setupCallbacks() {

[gaben]

Ah yes, the LaF workarounds should be set later in order to work.

So this version fixes both #20850 and #22253, confirmed.

[taylor.smock]

In 18751/josm:

Fix #20850 and #22253: Font size in TextAreas is very small in Windows (patch by gaben, modified)

This is due to JDK-6396936: Windows LaF has an incorrect font for TextArea.font.
The bug will most likely never be fixed due to backwards compatibility concerns.

Modifications are as follows:

• Move the workaround to be with other LaF workarounds
• Ensure that LaF workarounds are applied by calling them after the LaF is set.
• Add a check to the workaround to ensure that it will only be applied in known-bad configurations.