Skip to content

[Win32] Fix font metrics being scaled by GC transform for fallback fonts#3355

Open
HeikoKlare wants to merge 1 commit into
eclipse-platform:masterfrom
HeikoKlare:fix/issue-2978-fallback-font-transform-metrics
Open

[Win32] Fix font metrics being scaled by GC transform for fallback fonts#3355
HeikoKlare wants to merge 1 commit into
eclipse-platform:masterfrom
HeikoKlare:fix/issue-2978-fallback-font-transform-metrics

Conversation

@HeikoKlare
Copy link
Copy Markdown
Contributor

@HeikoKlare HeikoKlare commented Jun 1, 2026

Summary

Fixes #2978

When a font that does not exist on the platform is set on a GC and a Transform is active, GDI+ calls Font::GetLogFontW with the transformed Graphics to derive a fallback GDI font handle. This causes the lfHeight in the resulting LOGFONT to be scaled by the transform, so GetTextMetrics on the DC returns inflated (transform-scaled) metrics.

The fix temporarily saves and restores the GDI+ transform around the Font::GetLogFontW call so the LOGFONT always reflects device-pixel metrics, independent of any user-applied transform.

A regression test is added that verifies font metrics are consistent across all four combinations of transform-set/cleared and font-set/kept that the original issue demonstrated.

How to Test

The snippet from #2978 may be used for testing. That snippet reflects what is also done by the test added with this PR.

When a font that does not exist on the platform is set on a GC and a
Transform is active, GDI+ internally calls Font::GetLogFontW with the
transformed Graphics to derive a fallback GDI font handle. This caused
the lfHeight in the resulting LOGFONT to be scaled by the transform,
so GetTextMetrics on the DC returned inflated metrics.

Fix by temporarily saving and restoring the GDI+ transform around the
Font::GetLogFontW call so the LOGFONT always reflects device-pixel
metrics, independent of any user-applied transform.

Fixes eclipse-platform#2978

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@HeikoKlare HeikoKlare marked this pull request as ready for review June 1, 2026 20:27
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Jun 1, 2026

Test Results

  182 files  +   31    182 suites  +31   26m 27s ⏱️ + 6m 32s
4 730 tests +    1  4 707 ✅ +    1   23 💤 ± 0  0 ❌ ±0 
6 854 runs  +1 131  6 691 ✅ +1 090  163 💤 +41  0 ❌ ±0 

Results for commit 27aecd6. ± Comparison against base commit 9ab3898.

@HeikoKlare
Copy link
Copy Markdown
Contributor Author

@ptziegler I am not sure how severe #2978 still is for you, but this may be a solution to that issue

@ptziegler
Copy link
Copy Markdown
Contributor

@HeikoKlare I think we agreed that this problem primarily happens when using a non-existent font, right? The reason I originally reported this was due to the GEF Logic editor, but otherwise I've never seen it in practice. Especially when the "fix" is to use a valid font instead. 😅

@HeikoKlare
Copy link
Copy Markdown
Contributor Author

Yes, this problem should only happen when using a non-existent font (because the height calculation is wrong in exactly that case).
I remember that you reported the issue because of the numbers in the Logic editor, and I also agree that it should not happen that often in practice, as you should usually use/switch to a font that exists (on every OS you support) for proper UI results. I was just not sure if you may had faced that issue anywhere else as well 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Win32] Missing fonts don't play nice with FontMetrics and Transform

2 participants