-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Canary: rendering issue #17810
Comments
I'm afraid I can't really help you solve this problem, but if I can help you look up the code points in ucd.nounihan.grouped.xml, it might save you some time.
|
Looking at the list of other Spacing Marks it seems to me like we should assign them a non-zero width. The "spacing" means after all that they occupy their own space, unlike non-spacing marks. 🤔 |
The gaps are mostly a layout issue. Since we rely on font fallback, the given fallback fonts may simply have a different idea of what the advance width of the glyphs are. In fact, usually the fallback fonts are proportional while we expect monospace rendering. I think that's simply an issue we'll have to live with until someone designs a monospace font for that language. The extra gap at the end (near the quote) is the result from my text layout in AtlasEngine. Centering glyphs in their cell isn't quite as trivial as it may initially seem, because ligatures can seemingly form across arbitrary columns (after shaping). It's way way simpler to implement this by left-aligning all glyphs. We're tracking that issue here: #16656 |
Spacing marks are called so, because they have a positive advance width, unlike their non-spacing neighbors (as the name indicates). After this we stop assigning such gc=Mc codepoints a zero width. Closes #17810 (cherry picked from commit 0cb3426) Service-Card-Id: PVTI_lADOAF3p4s4AmhmQzgSg1L4 Service-Version: 1.22
Windows Terminal version
Canary v. 1.22.2351.0
Windows build number
10.0.22631.4037
Other Software
VS Code for reference
Steps to reproduce
The batch script used to generate the output is
... saved UTF-8 (no BOM) encoded.
Expected Behavior
Readable text 😉 Preferably rendered as in the screenshot of VS Code.
Actual Behavior
Before I say anything - the new width measuring of grapheme clusters in v.1.22 is far better than what we ever had before. I love how Terminal's Unicode support is getting better and better.
I'm still playing around to see how it behaves. Scripts like Devanagari did never work correctly. But even the rendering of this has been improved a lot in most cases now.
However, sometimes there are visual effects that I'd consider a regression since overlapping makes text almost unreadable in a usual font size (the font in every window of the screenshot below is Cascadia Mono btw.).
The screenshot shows:
cc @lhecker
The text was updated successfully, but these errors were encountered: