Windows Terminal v1.19.11213.0

[DHowett]

This is probably the last servicing release for 1.19 before Stable moves on to 1.20, but I couldn't resist getting
some changes out to my favorite userbase!

Changes

• Terminal now comes with Cascadia Code 2404.23, which has a couple hundred new glyphs! (Update Cascadia Code to 2404.23 #17137)
• We've moved to the latest Azure Cloud Shell API version to prevent it from breaking on you (Update Azure Cloud Shell API to the newer version #17115)

Bug Fixes

• Hidden cursors will no longer sometimes reappear unexpectedly (Fix the DECTCEM reset position in the conpty stream #17148) (thanks @j4james!)
• Maximizing a minimized window will no longer move your viewport around mysteriously (Fix window style under minimized state #17058) (thanks @tusharsnx!)
• We've fixed a number of UI style errors in menu item capitalization and our use of ellipses (...) (Fix: UI style errors: Menu items capitalization and … (ellipses) mark misuse #16886) (thanks @HarshNarayanJha!)

---

Binary files inside the unpackaged distribution archive bear the version number 1.19.240430003.

Asset Hashes

• Microsoft.WindowsTerminal_1.19.11213.0_8wekyb3d8bbwe.msixbundle_Windows10_PreinstallKit.zip
  • SHA256 BF1217A67A04816B0E0D07318CF2245C40A6BD2FF9186D5C2B7D5279A52DADC2
• Microsoft.WindowsTerminal_1.19.11213.0_8wekyb3d8bbwe.msixbundle
  • SHA256 396441548B00948FBA360F6CA7033B554B429A023FA00FC01330FB1D39923FE1
• Microsoft.WindowsTerminal_1.19.11213.0_arm64.zip
  • SHA256 A6AD2515F5BF4EBF0B7256B0F88EB16722ACDD627298D1862BA66B76C5929179
• Microsoft.WindowsTerminal_1.19.11213.0_x64.zip
  • SHA256 E32D7E72F8490AD94174708BB0B420E1EF4467B92F442D40DFAFDF42202A16A7
• Microsoft.WindowsTerminal_1.19.11213.0_x86.zip
  • SHA256 95993363FC53E0F0FBF8CDA11807F66B899EE8E16803384630CF7841ECC933A0

---

This discussion was created from the release Windows Terminal v1.19.11213.0.

[SkewelVsAll]

Damn, still nothing for the Context Menu entry problems on Windows 10?

[zadjii-msft]

Nope. There haven't been any updates posted to #14185, so I wouldn't expect anything new in this release (or 1.21). We'd be happy to accept a community contribution for that, but let's have that discussion over in the original thread 😉

[pedro-w]

I was trying to have a look at the new Cascadia but without success.

I made this python program to look at the outline digits (1CCF0-9) which I believe should be in the new font.

segs = [chr(i + 0x1CCF0) for i in range(10)]
with open("me.txt", "w", encoding='utf-16') as fo:
    print(''.join(segs), file=fo)

but I just see the '? in a diamond' . I assume I'm doing something wrong, does anyone know a way to show the new glyphs?

Windows 11, 22H2
Windows Terminal
Version: 1.19.11213.0

me.txt

[pedro-w]

I did try that with no difference. I noticed in the PR that @DHowett posted a curl'able URI - if I do that it, I see the correct 'Windows Terminal' text. Also I can print out the 256 characters from 0x1FB00 which matches another of the screenshots. So it's just the range from 0x1CCF0 that doesn't work for me. Have I got the wrong range of codepoints perhaps? Can anyone else see those particular glyphs using my python script, or otherwise?

[lhecker]

I'm not entirely sure why the PR says "U+1CCF0" for the "segmented digits", but the correct codepoints for that start at U+1FBF0 and that seems to work great!

FYI I'd avoid writing text files in UTF-16 if possible, and instead use UTF-8. People usually point to http://utf8everywhere.org/ for an explanation as to why UTF-8 is preferable.

[pedro-w]

Alright, that makes sense. U+1CCF0 is the start of the 'outline' digits and they're not implemented (yet!). Just my luck I picked those codepoints to test the new font.
Re: UTF-8 I totally agree, but UTF-16 is still the default encoding for cating a file in powershell, isn't it.

[lhecker]

cat is an alias for Get-Content which has an -Encoding parameter. Its default in modern powershell (v6, v7) is utf8NoBOM. I'm not sure what it was in older versions, but I don't think it was ever UTF-16. It probably only works because it detects the BOM.

[pedro-w]

Going a bit off topic here - but if I change the encoding in my python program to encoding='utf-8' then I just get junk.

> cat me.py ; python me.py; cat me.txt
segs = [chr(i + 0x1FBF0) for i in range(10)]
with open("me.txt", "w", encoding='utf-8') as fo:
    print(''.join(segs), file=fo)
🯰🯱🯲🯳🯴🯵🯶🯷🯸🯹

If I cat -encoding utf8 me.txt then I see the true segmented digits, alternatively encoding='utf-8-sig' works (or encoding='utf-16' of course) both, as you say, because of the BOM.

PSVersion = 5.1.22621.2506 for me, I haven't updated from whatever came with Win11. I do know > aka Out-File will write UTF-16 on this version, probably that's why I assumed Get-Content likewise would default to UTF-16. I just want a simple life!