starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Glyphs scalling is not accurate #8127

New Issue
Closed
opened 2026-01-31 01:21:23 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 01:21:23 +00:00
Owner
Copy Link

Originally created by @kasper93 on GitHub (May 13, 2020).

Those are panes separators in tmux, as you can see after mentioned change vertical line is wider than horizontal one, which is in my opinion looks really bad, if you have direct comparison. Mintty does it right. The same font in both cases.

Before commit 70867df077:

image

After commit 70867df077:

image

Mintty:

image

Originally created by @kasper93 on GitHub (May 13, 2020). Those are panes separators in tmux, as you can see after mentioned change vertical line is wider than horizontal one, which is in my opinion looks really bad, if you have direct comparison. Mintty does it right. The same font in both cases. ### Before commit 70867df077e03a8ac5d4b230e28d64f90e08045e: ![image](https://user-images.githubusercontent.com/1126053/81860633-4df08580-9567-11ea-8d1b-c63ccca226d5.png) ### After commit 70867df077e03a8ac5d4b230e28d64f90e08045e: ![image](https://user-images.githubusercontent.com/1126053/81860699-6496dc80-9567-11ea-8d21-d81a4c5522ef.png) ### Mintty: ![image](https://user-images.githubusercontent.com/1126053/81860771-81331480-9567-11ea-8669-241fd5956c65.png)
claunia added the Resolution-By-DesignNeeds-Tag-Fix labels 2026-01-31 01:21:24 +00:00
claunia commented 2026-01-31 01:21:25 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 13, 2020):

It's not really wider, though, it's just brighter because we're not splitting it on the half pixel... that seems to be consistent with the traditional CP437 rendering of those glyphs (where the verticals are thicker than the horizontals)

@DHowett-MSFT commented on GitHub (May 13, 2020): It's not really wider, though, it's just _brighter_ because we're not splitting it on the half pixel... that seems to be consistent with the traditional CP437 rendering of those glyphs (where the verticals are thicker than the horizontals)
claunia commented 2026-01-31 01:21:25 +00:00
Author
Owner
Copy Link

@kasper93 commented on GitHub (May 13, 2020):

I took closeup look and counted pixels. Looks like it is 1px wider, but well, as you said it is also brighter, I though it looks brighter because it is wider and you say otherwise :)

Anyhow I didn't notice similar rendering in other terminal emulators. I mean I immediately noticed that something is wrong here. If you google tmux screenshots vertical and horizontal separators looks the same almost everywhere. I use the same font (Hack) in mintty and gnome terminal and looks fine.

@kasper93 commented on GitHub (May 13, 2020): I took closeup look and counted pixels. Looks like it is 1px wider, but well, as you said it is also brighter, I though it looks brighter because it is wider and you say otherwise :) Anyhow I didn't notice similar rendering in other terminal emulators. I mean I immediately noticed that something is wrong here. If you google tmux screenshots vertical and horizontal separators looks the same almost everywhere. I use the same font (Hack) in mintty and gnome terminal and looks fine.
claunia commented 2026-01-31 01:21:25 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 14, 2020):

Sorry - I didn't see the extra pixel because I trusted my browser's upscaler to use nearest-neighbor 😄

So, I'm going to resolve this one by design and file a followup work item. Before I do that, though, a bit of backstory and an explanation for why it is the way it is.

In the old terrible days, we could be relatively sure (cf. the traditional console's GDI renderer) that our font sizes were in absolute pixels. This left no possibility of fractional sizes for ascent, descent, or line spacing (as computed by the text layout engine.)

When we moved to using DirectWrite, we started to avail ourselves of the ability to do differential rendering and using an API that lets us only present changed regions (and do really fast scrolling by asking the graphics card to move the region for us.)

Those APIs only work on full pixel boundaries. Unfortunately, fonts are weird and when you try to render them in a nice grid sometimes you need to bump them around by fractional pixels. This didn't jive with the presentation API.

Terminal rounds a glyph's box size up to the nearest pixel, and adjusts the font size inside it for best fit. Doing this broke box/line drawing characters completely: they had gaps in the vertical direction, or gaps in the horizontal direction, because they no longer fit the cells we gave them. Whoops.

#5743 introduced a change that measures the four edges of a box or line glyph for any given font and scales it just a bit to touch the pixel-locked bounds we want to render it in. The result is consistent with the font's style, but stretched out a little bit in certain dimensions.

The tradeoff we made was to have contiguous box-drawing glyphs at the cost of having perfectly-sized box-drawing glyphs.

Other terminal emulators do interesting things:

  • Gnome-terminal uses little 5x5 bitmaps and stretches them to fill the entire cell.
    • This results in pixel perfect boxes and shading.
  • Konsole (KDE) uses line-drawing primitives at the graphics layer to mimic line drawing, and rect-filling primitives with opacity to mimic box drawing.
    • This also results in pixel-perfect boxes and cool blended shading glyphs.

We chose not to do these things for v1.0 because we learned that certain fonts (monofur is a good one) have their own unique styles for line glyphs (and box fills, but that's beside the point) that we wanted to preserve.

For post-v1, I'm willing to accept that this might not be the best way to handle it. I've filed a followup workitem, #5897, to encourage us to investigate different ways to handle these glyphs.

@DHowett-MSFT commented on GitHub (May 14, 2020): Sorry - I didn't see the extra pixel because I trusted my browser's upscaler to use nearest-neighbor :smile: So, I'm going to resolve this one by design and file a followup work item. Before I do that, though, a bit of backstory and an explanation for why it is the way it is. In the old terrible days, we could be relatively sure (cf. the traditional console's GDI renderer) that our font sizes were in absolute pixels. This left no possibility of fractional sizes for ascent, descent, or line spacing (as computed by the text layout engine.) When we moved to using DirectWrite, we started to avail ourselves of the ability to do differential rendering and using an API that lets us only present changed regions (and do really fast scrolling by asking the graphics card to move the region for us.) Those APIs only work on full pixel boundaries. _Unfortunately,_ fonts are weird and when you try to render them in a nice grid sometimes you need to bump them around by fractional pixels. This didn't jive with the presentation API. Terminal rounds a glyph's box size up to the nearest pixel, and adjusts the font size inside it for best fit. Doing this broke box/line drawing characters completely: they had gaps in the vertical direction, or gaps in the horizontal direction, because they no longer fit the cells we gave them. Whoops. #5743 introduced a change that measures the four edges of a box or line glyph for any given font and scales it just a bit to touch the pixel-locked bounds we want to render it in. The result is consistent with the font's style, but stretched out a little bit in certain dimensions. The tradeoff we made was to have _contiguous_ box-drawing glyphs at the cost of having _perfectly-sized_ box-drawing glyphs. --- Other terminal emulators do interesting things: * Gnome-terminal uses little 5x5 bitmaps and stretches them to fill the entire cell. * This results in pixel perfect boxes and shading. * Konsole (KDE) uses line-drawing primitives at the graphics layer to mimic line drawing, and rect-filling primitives with opacity to mimic box drawing. * This also results in pixel-perfect boxes _and_ cool blended shading glyphs. We chose not to do these things _for v1.0_ because we learned that certain fonts (monofur is a good one) have their own unique styles for line glyphs (and box fills, but that's beside the point) that we wanted to preserve. For post-v1, I'm willing to accept that this might not be the best way to handle it. I've filed a followup workitem, #5897, to encourage us to investigate different ways to handle these glyphs.
claunia commented 2026-01-31 01:21:25 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 14, 2020):

(The body of commit 70867df077 has more details about why we chose to do it this way. 😄)

@DHowett-MSFT commented on GitHub (May 14, 2020): (The body of commit https://github.com/microsoft/terminal/commit/70867df077e03a8ac5d4b230e28d64f90e08045e has more details about why we chose to do it this way. :smile:)
claunia commented 2026-01-31 01:21:25 +00:00
Author
Owner
Copy Link

@kasper93 commented on GitHub (May 14, 2020):

Thank you for comprehensive answer and creating followup work item 👍

@kasper93 commented on GitHub (May 14, 2020): Thank you for comprehensive answer and creating followup work item 👍
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Needs-Tag-Fix Resolution-By-Design
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#8127
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?