Windows: `text-field%` clips top of glyphs when display scaling >100% (after 2nd character)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Ambito
- desktop, operating-systems
Direzione di ricerca
Inizia eseguendo su Windows la riproduzione fornita di racket/gui con una ridimensionamento dello schermo al 125%, quindi ispeziona l’editor text-field% e il rendering di editor canvas o il percorso vertical-metric. Confronta i ridisegni di uno e due caratteri, inclusi i casi di padding. Il lavoro è completato quando i glifi non vengono più ritagliati nei campi elencati con una scala superiore al 100%, senza introdurre un ritaglio nella parte inferiore.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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
- Run the program below.
- Click into the Default field.
- Type a single uppercase character (e.g.
P): renders correctly. - 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-paddingon 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) from0to3had 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-heightdoes 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.
- Lingua principale
- Racket
- Stelle
- 68
- Fork
- 83
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di racket/gui
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
[Package Request]: Raven ApertaHelp-Wanted Package-Request
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
microsoft/winget-pkgs#438682 ·
-
Daemon passes --experimental-wasm-jspi unconditionally on Node >= 24; Node 26 rejects the flag Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
Automattic/studio#4908 ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
os:macos
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100