Windows: `text-field%` clips top of glyphs when display scaling >100% (after 2nd character)

[joeld-win]

On Windows, when display scaling is set to a value >100% (125% in my case) a single-line text-field% correctly renders one character, but as soon as a second character is typed, the top of all visible glyphs becomes clipped by a few pixels. The effect applies uniformly across the entire entered string: characters typed earlier also become clipped once a second character is added.

• Racket version: 9.0 and 9.1 (screenshots use 9.1)
• OS: Windows 11 Pro (24H2 / 63100.8037)
• Display scaling: 125%

Reproduction

1. Run the program below.
2. Click into the Default field.
3. Type a single uppercase character (e.g. P): renders correctly.
4. Type a second character (e.g. another P): tops of both characters are now clipped.

#lang racket/gui

(define frame
  (new frame% [label "text-field clipping repro"] [width 540] [height 380]))

(define container
  (new vertical-pane% [parent frame] [border 24] [spacing 14] [alignment '(left top)]))

(new message% [parent container] [label "Type 2+ characters into each field to compare:"])
(new text-field% [parent container] [label "Default:"])
(new text-field% [parent container] [label "min-height 28:"] [min-height 28])
(new text-field% [parent container] [label "min-height 32:"] [min-height 32])

(define padded
  (new text-field% [parent container] [label "editor padding 0 3 0 3:"]))
(send (send padded get-editor) set-padding 0 3 0 3)

(new text-field% [parent container] [label "14pt font:"] [font (make-object font% 14 'default)])

(send frame show #t)

After typing PPg into each field:

Field	Result
Default	Tops of both Ps clipped; g complete.
min-height 28	Same clipping as default.
min-height 32	Same clipping as default.
set-padding 0 3 0 3 on editor	Top no longer clipped, but descender of g is now clipped at the bottom.
14pt font	Top of P partially visible but still clipped.

Workarounds attempted

• Increasing min-height (28, 32): does not fix the clipping.
• set-padding on the underlying editor: passing a top padding (2nd argument) shifts the text down so ascenders are no longer clipped, but the descenders are then clipped at the bottom instead. Changing the bottom padding (4th argument) from 0 to 3 had no observable effect.
• Larger font: reduces but does not eliminate the clipping.

Notes

• Changing Windows display settings from 125% to 100% scaling on all monitors and restarting DrRacket eliminates the clipping in all five fields, including the default. This points to a DPI scaling issue in the editor canvas's vertical metric or offset computation rather than a font/control issue per se.
• Clipping only appears once the line contains a second character. With exactly one character, rendering is correct in all fields. This may be a useful diagnostic; something in the redraw or layout path appears to be invoked or recalculated only when a line contains more than one snip.
• The fact that min-height does not eliminate the clipping suggests the cause is not simply that the canvas is too short — the text appears to be positioned with an incorrect vertical offset relative to the canvas, rather than the canvas lacking room for it.
• It seems set-padding's top parameter shifts the text, but the bottom parameter has no observable effect. May warrant separate investigation.

[alex-hhh]

I can reproduce the issue you reported at 125% scaling but not at 150% using Racket 9.1

I also noticed similar issues with font rendering directly in canvas objects, but not for every font size, and I didn't have time to track it down further.

Also, in my case, this problem started happening in Racket 8.15, but not when I originally installed it, so I suspect one of the Windows updates changed something about how font rendering works.