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

Do we still need to force the font on output codepage change? #14319

New Issue
Closed
opened 2026-01-31 04:07:04 +00:00 by claunia · 11 comments
claunia commented 2026-01-31 04:07:04 +00:00
Owner
Copy Link

Originally created by @alabuzhev on GitHub (Jun 22, 2021).

Description of the new feature/enhancement

Currently, when the user changes the console codepage (manually or via a script) the GDI engine tries to find and set the "best possible" font. The "best possible" here is charset-wise, it doesn't mean that the font is actually better or more eye-candy for the user.

Example:

  • Open cmd
  • Set the font to Consolas
  • Enter chcp 932
  • Suddenly, a wild MS Gothic appears!

This kind of makes sense ("if I'm changing the codepage I probably want to see the national characters") but it doesn't happen anywhere else - all other apps just substitute the missing glyphs.

After #10472 / #10478 this magic should finally work here as well. So, do we still need to change the whole font? Terminal doesn't do that after all.

Proposed technical implementation details

A quick and dirty hack, I'm sure there are better ways:

diff --git a/src/host/misc.cpp b/src/host/misc.cpp
index a89c982b..64f602d1 100644
--- a/src/host/misc.cpp
+++ b/src/host/misc.cpp
@@ -38,6 +38,7 @@ void SetConsoleCPInfo(const BOOL fOutput)
         // to pick a more appropriate font should the current one be unable to render in the new codepage.
         // To do this, we create a copy of the existing font but we change the codepage value to be the new one that was just set in the global structures.
         // NOTE: We need to do this only if everything is set up. This can get called while we're still initializing, so carefully check things for nullptr.
+#if 0
         if (gci.HasActiveOutputBuffer())
         {
             SCREEN_INFORMATION& screenInfo = gci.GetActiveOutputBuffer();
@@ -54,6 +55,7 @@ void SetConsoleCPInfo(const BOOL fOutput)
                            gci.OutputCP);
             screenInfo.UpdateFont(&fiNew);
         }
+#endif
 
         if (!GetCPInfo(gci.OutputCP, &gci.OutputCPInfo))
         {

Testing

Download 932.cmd.txt, rename to 932.cmd, run it, check if the output is still readable.

Originally created by @alabuzhev on GitHub (Jun 22, 2021). # Description of the new feature/enhancement Currently, when the user changes the console codepage (manually or via a script) the GDI engine tries to find and set the "best possible" font. The "best possible" here is charset-wise, it doesn't mean that the font is actually better or more eye-candy for the user. Example: - Open cmd - Set the font to Consolas - Enter `chcp 932` - Suddenly, a wild MS Gothic appears! This kind of makes sense (*"if I'm changing the codepage I probably want to see the national characters"*) but it doesn't happen anywhere else - all other apps just substitute the missing glyphs. After #10472 / #10478 this magic should finally work here as well. So, do we still need to change the whole font? Terminal doesn't do that after all. # Proposed technical implementation details A quick and dirty hack, I'm sure there are better ways: ```DIFF diff --git a/src/host/misc.cpp b/src/host/misc.cpp index a89c982b..64f602d1 100644 --- a/src/host/misc.cpp +++ b/src/host/misc.cpp @@ -38,6 +38,7 @@ void SetConsoleCPInfo(const BOOL fOutput) // to pick a more appropriate font should the current one be unable to render in the new codepage. // To do this, we create a copy of the existing font but we change the codepage value to be the new one that was just set in the global structures. // NOTE: We need to do this only if everything is set up. This can get called while we're still initializing, so carefully check things for nullptr. +#if 0 if (gci.HasActiveOutputBuffer()) { SCREEN_INFORMATION& screenInfo = gci.GetActiveOutputBuffer(); @@ -54,6 +55,7 @@ void SetConsoleCPInfo(const BOOL fOutput) gci.OutputCP); screenInfo.UpdateFont(&fiNew); } +#endif if (!GetCPInfo(gci.OutputCP, &gci.OutputCPInfo)) { ``` # Testing Download [932.cmd.txt](https://github.com/microsoft/terminal/files/6697577/932.cmd.txt), rename to 932.cmd, run it, check if the output is still readable.
claunia commented 2026-01-31 04:07:05 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 29, 2021):

Yeah that sounds like a good idea to me. 👍

@lhecker commented on GitHub (Jun 29, 2021): Yeah that sounds like a good idea to me. 👍
claunia commented 2026-01-31 04:07:06 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 7, 2021):

I'm gonna let @miniksa have the say on this - it seems like a good idea to me, but he's got more historical perspective on this specific bit of the codebase

@zadjii-msft commented on GitHub (Jul 7, 2021): I'm gonna let @miniksa have the say on this - it seems like a good idea to me, but he's got more historical perspective on this specific bit of the codebase
claunia commented 2026-01-31 04:07:06 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jul 7, 2021):

It seems like a decent idea in theory, but I am concerned about not getting a yen symbol on backslash in codepage 932. As far as I'm aware, that's a font substitution that is a part of MS Gothic and wouldn't necessarily be resolved by fallback if the base font was Consolas.

The problem lies strictly with the https://github.com/microsoft/terminal/issues/217#issuecomment-404240443 story but with someone emergency stopping the factory line because the yen symbol is now a backslash and doesn't match the printout picture of what it's supposed to look like.

@miniksa commented on GitHub (Jul 7, 2021): It seems like a decent idea in theory, but I am concerned about not getting a yen symbol on backslash in codepage 932. As far as I'm aware, that's a font substitution that is a part of MS Gothic and wouldn't necessarily be resolved by fallback if the base font was Consolas. The problem lies strictly with the https://github.com/microsoft/terminal/issues/217#issuecomment-404240443 story but with someone emergency stopping the factory line because the yen symbol is now a backslash and doesn't match the printout picture of what it's supposed to look like.
claunia commented 2026-01-31 04:07:06 +00:00
Author
Owner
Copy Link

@alabuzhev commented on GitHub (Jul 7, 2021):

@miniksa are you implying that there are people in the wild who:

  • have a CJK system locale (because dynamic switching to CJK codepages without a CJK locale is a relatively recent addition, if I'm not mistaken)
  • set a non-932 codepage initially
  • change it to 932 at some point
  • use optical recognition software or specially trained people to spot a yen symbol in a particular point of the screen (because programmatical methods like ReadConsoleOutput / ReadConsoleOutputCharacter would still return a backslash)
  • build factory lines on top of all that?

Looking at it through these horror-colored glasses, I'm afraid that #10478 has already broken the world - after all, someone somewhere could have expected a replacement character instead of a proper glyph :)

@alabuzhev commented on GitHub (Jul 7, 2021): @miniksa are you implying that there are people in the wild who: - have a CJK system locale (because dynamic switching to CJK codepages without a CJK locale is a relatively recent addition, if I'm not mistaken) - set a non-932 codepage initially - change it to 932 at some point - use optical recognition software or specially trained people to spot a yen symbol in a particular point of the screen (because programmatical methods like ReadConsoleOutput / ReadConsoleOutputCharacter would still return a backslash) - build factory lines on top of all that? Looking at it through these horror-colored glasses, I'm afraid that #10478 has already broken the world - after all, someone somewhere could have expected a replacement character instead of a proper glyph :)
claunia commented 2026-01-31 04:07:06 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jul 7, 2021):

@miniksa are you implying that there are people in the wild who:

  • have a CJK system locale (because dynamic switching to CJK codepages without a CJK locale is a relatively recent addition, if I'm not mistaken)
  • set a non-932 codepage initially
  • change it to 932 at some point
  • use optical recognition software or specially trained people to spot a yen symbol in a particular point of the screen (because programmatical methods like ReadConsoleOutput / ReadConsoleOutputCharacter would still return a backslash)
  • build factory lines on top of all that?

image

Looking at it through these horror-colored glasses, I'm afraid that #10478 has already broken the world - after all, someone somewhere could have expected a replacement character instead of a proper glyph :)

Probably. I'm less worried about a glyph appearing where a box did prior and more worried about substituting one glyph for another. I just have the feeling that the specially trained person on the assembly line isn't going to hit the Emergency Stop button halting the production of millions of dollars of outsourced computers invoking the ire of the multinationals who subcontracted them to build said computers and then calling our EVPs to ask WTF over seeing an emoji where there was a square versus seeing a backslash where there was a yen symbol.

@miniksa commented on GitHub (Jul 7, 2021): > @miniksa are you implying that there are people in the wild who: > > * have a CJK system locale (because dynamic switching to CJK codepages without a CJK locale is a relatively recent addition, if I'm not mistaken) > * set a non-932 codepage initially > * change it to 932 at some point > * use optical recognition software or specially trained people to spot a yen symbol in a particular point of the screen (because programmatical methods like ReadConsoleOutput / ReadConsoleOutputCharacter would still return a backslash) > * build factory lines on top of all that? ![image](https://user-images.githubusercontent.com/18221333/124817998-594b0100-df1f-11eb-91e4-c23b3757ea1d.png) > Looking at it through these horror-colored glasses, I'm afraid that #10478 has already broken the world - after all, someone somewhere could have expected a replacement character instead of a proper glyph :) Probably. I'm less worried about a glyph appearing where a box did prior and more worried about substituting one glyph for another. I just have the feeling that the specially trained person on the assembly line isn't going to hit the Emergency Stop button halting the production of millions of dollars of outsourced computers invoking the ire of the multinationals who subcontracted them to build said computers and then calling our EVPs to ask WTF over seeing an emoji where there was a square versus seeing a backslash where there was a yen symbol.
claunia commented 2026-01-31 04:07:06 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jul 7, 2021):

I guess... I do hear you on the.... we only allowed the dynamic changing of codepages relatively recently. We could maybe presume that they're not changing it dynamically like that. But I dunno. I'm not sure I want to take the risk on this unless it's really really driving something important.

@miniksa commented on GitHub (Jul 7, 2021): I guess... I do hear you on the.... we only allowed the dynamic changing of codepages relatively recently. We could maybe presume that they're not changing it dynamically like that. But I dunno. I'm not sure I want to take the risk on this unless it's really really driving something important.
claunia commented 2026-01-31 04:07:07 +00:00
Author
Owner
Copy Link

@alabuzhev commented on GitHub (Jul 7, 2021):

Such worries are probably exaggerated a little. Yes, there are weird workflows. Yes, there's Hyrum's Law. But something makes me think that people who do need consistency and backward compatibility in the first place don't use the new conhost at all, opting in for legacy console (or still run their factory lines on Windows XP, if not NT4). Because with all the recent features you've already broken a lot :) The holy grail of compatibility - batch files - are now working totally differently in certain cases, because what used to be pseudographics is now escape sequences and echo Look, an arrow in brackets!: [←] doesn't really do what it used to do.

Anyway, it's up to you guys of course.
This particular case is nowhere near from my daily scenarios, rather a weird quirk I observed.

@alabuzhev commented on GitHub (Jul 7, 2021): Such worries are probably exaggerated a little. Yes, there are weird workflows. Yes, there's Hyrum's Law. But something makes me think that people who do need consistency and backward compatibility in the first place don't use the new conhost at all, opting in for legacy console (or still run their factory lines on Windows XP, if not NT4). Because with all the recent features you've already broken *a lot* :) The holy grail of compatibility - batch files - are now working totally differently in certain cases, because what used to be pseudographics is now escape sequences and `echo Look, an arrow in brackets!: [←]` doesn't really do what it used to do. Anyway, it's up to you guys of course. This particular case is nowhere near from my daily scenarios, rather a weird quirk I observed.
claunia commented 2026-01-31 04:07:07 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jul 7, 2021):

I'm just gun shy because I hate email from my executives addressed directly to me. You're probably right, @alabuzhev. I think I can be convinced that this is an appropriate time and space to cut this and see what happens. But I'd want @DHowett to weigh in as he's the lead.

@miniksa commented on GitHub (Jul 7, 2021): I'm just gun shy because I hate email from my executives addressed directly to me. You're probably right, @alabuzhev. I think I can be convinced that this is an appropriate time and space to cut this and see what happens. But I'd want @DHowett to weigh in as he's the lead.
claunia commented 2026-01-31 04:07:07 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Jul 8, 2021):

@DHowett and I talked about this today. Let's do it, @alabuzhev. We'll see what happens and adjust later if we must.

@miniksa commented on GitHub (Jul 8, 2021): @DHowett and I talked about this today. Let's do it, @alabuzhev. We'll see what happens and adjust later if we must.
claunia commented 2026-01-31 04:07:07 +00:00
Author
Owner
Copy Link

@alabuzhev commented on GitHub (Jul 8, 2021):

@DHowett and I talked about this today. Let's do it, @alabuzhev. We'll see what happens and adjust later if we must.

@miniksa ok, I've created #10497 that simply removes the font code from SetConsoleCPInfo.

@alabuzhev commented on GitHub (Jul 8, 2021): > @DHowett and I talked about this today. Let's do it, @alabuzhev. We'll see what happens and adjust later if we must. @miniksa ok, I've created #10497 that simply removes the font code from `SetConsoleCPInfo`.
claunia commented 2026-01-31 04:07:08 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 14, 2021):

:tada:This issue was addressed in #10591, which has now been successfully released as Windows Terminal Preview v1.10.1933.0.🎉

Handy links:

@ghost commented on GitHub (Jul 14, 2021): :tada:This issue was addressed in #10591, which has now been successfully released as `Windows Terminal Preview v1.10.1933.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.10.1933.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
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 Area-Fonts Area-Rendering Issue-Task Product-Conhost Resolution-Fix-Committed
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#14319
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?