Investigate font size inconsistency across SWT platforms (macOS vs Windows/Linux)

[Copilot]

Fonts with identical point sizes render 25% smaller on macOS compared to Windows/Linux. This investigation analyzes the root cause and proposes concrete solutions.

Investigation Summary

Root Cause: SWT implicitly assumes 96 DPI as the logical baseline across all platforms, but macOS natively uses 72 DPI (PostScript convention: 1pt = 1/72"). The conversion formula size = height * dpi / screenDPI is mathematically correct but produces visually inconsistent results:

Windows/Linux: 72pt × (96/96) = 72 at 96 DPI → 0.75" physical
macOS:         72pt × (72/72) = 72 at 72 DPI → 1.0" physical  
Visual ratio: 72/96 = 0.75 (25% smaller on macOS)

Deliverables

Technical Analysis (docs/font-size-inconsistency-investigation.md)

• Platform-by-platform code examination of Font.init() and Device.getScreenDPI()
• Mathematical proof of 25% size difference
• Historical context: Windows chose 96 DPI for CRT displays, macOS chose 72 DPI for typography
• Evidence from test cases showing ~50% vs ~70% box fill ratios

Solution Proposals (docs/font-size-inconsistency-mitigations.md)

Solution 1 (Quick fix): Normalize macOS DPI

// cocoa/Device.java - getScreenDPI()
return new Point(96, 96);  // Instead of native 72

• One-line change, immediate cross-platform consistency
• Trade-off: Semantically incorrect DPI value

Solution 2 (Proper fix): Font-level normalization

// cocoa/Font.java - init()
private static final int NORMALIZED_DPI = 96;
float size = height * NORMALIZED_DPI / screenDPI.y;  // Explicit baseline

• Preserves accurate getScreenDPI() for printing
• Isolated to Font class

Solution 3 (Long-term): Configuration API

// New Device methods
public void setLogicalDPI(int dpi);
public int getLogicalDPI();
public Point getPhysicalDPI();

// New GC methods  
public void setFontRenderingMode(int mode);
// FONT_MODE_NATIVE (72 DPI on macOS) vs FONT_MODE_NORMALIZED (96 DPI)

• Explicit control, backward-compatible defaults
• Replaces deprecated getDPI()

Solution 4: Replacement APIs for deprecated getDPI() with clear semantics

Validation Tool (Snippet_FontConsistencyTest.java)

Visual test snippet with:

• Grid overlay for size comparison
• Font metrics display (height, ascent, descent)
• Pass/fail check (expects 70% box fill ratio)
• Platform and DPI information

Executive Summary (docs/font-size-inconsistency-summary.md)

High-level overview with roadmap, FAQ, migration guide

Recommended Path

1. Phase 1 (1-2 weeks): Implement Solution 1 for immediate fix
2. Phase 2 (1-2 months): Implement Solution 3 for proper API
3. Phase 3: Optionally implement Solution 2 for semantic correctness

Current Workaround (Can Be Removed After Fix)

// Applications currently compensate manually:
int DPI = Display.getCurrent().getDPI().y;
float factor = (float)96 / DPI;  // 1.33× on macOS
int newHeight = (int)(fontHeight * factor);

This investigation provides the technical foundation for addressing issue eclipse-platform#2925 with minimal breaking changes and clear migration paths.

Original prompt

Here I made two possible assumptions about the root cause of a problem of inconsitetn font sizes between the SWT platforms: eclipse-platform#2925 (comment)

The task would be to carefully investigate about the tow options, create a summary of the results and suggest possible mitigations in the SWT code base.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.