Skip to content
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

Unicode Box drawings characters not rendered correctly (disappear) with Japanese fonts #13527

Closed
kissge opened this issue Jul 18, 2022 · 4 comments · Fixed by #14959
Closed
Labels
Area-Fonts Related to the font Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Help Wanted We encourage anyone to jump in on these. In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Priority-2 A description (P2) Product-Terminal The new Windows Terminal.
Milestone

Comments

@kissge
Copy link

kissge commented Jul 18, 2022

Windows Terminal version

1.13.11432.0

Windows build number

10.0.22000.0

Other Software

MyricaM https://github.com/tomokuni/Myrica/raw/master/product/MyricaM.7z
Ricty Diminished https://github.com/mzyy94/RictyDiminished-for-Powerline/blob/master/RictyDiminished-Regular.ttf

Steps to reproduce

  1. Set font face to e.g. MyricaM M.
  2. Print characters like U+2500 BOX DRAWINGS LIGHT HORIZONTAL and U+2502 BOX DRAWINGS LIGHT VERTICAL by running e.g. tree.
/tmp/test
├── bar
│   └── baz
└── foo

1 directory, 2 files

Expected Behavior

and are printed.

Actual Behavior

Those characters are rendered improperly.

MyricaM M ... vertical bars are missing, and horizontal bars have wrong width

myricam

Ricty Diminished ... horizontal bars are missing

ricty

Lucida Console ... OK (though Japanese characters fall back to another font (I can't tell which font), causing weird spacing between letters)

lucida_console

@kissge kissge added the Issue-Bug It either shouldn't be doing this or needs an investigation. label Jul 18, 2022
@ghost ghost added Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Jul 18, 2022
@zadjii-msft zadjii-msft added Help Wanted We encourage anyone to jump in on these. Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Area-Fonts Related to the font Product-Terminal The new Windows Terminal. Priority-2 A description (P2) labels Jul 18, 2022
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Jul 18, 2022
@zadjii-msft zadjii-msft added this to the 22H2 milestone Jul 18, 2022
@zadjii-msft
Copy link
Member

Huh. Thanks for the report! Dunno why this would be happening. Hopefully this gets fixed with the new experimental text renderer, we'll see.

@lhecker
Copy link
Member

lhecker commented Jul 18, 2022

That font is Yu Gothic UI Regular.
Yu Gothic UI Regular

Yu Gothic is a proportional font according to Wikipedia and if that's correct we should probably pick MS Gothic instead:
MS Gothic Regular

In either case, the good news is that this issue doesn't occur with the experimental text rendering engine ("AtlasEngine"):
image

The line drawings have significant gaps now unfortunately, but at least they're visible and it's an issue that I'm currently planning to improve on in the near-ish future.

@kissge
Copy link
Author

kissge commented Jul 19, 2022

In either case, the good news is that this issue doesn't occur with the experimental text rendering engine ("AtlasEngine"):

Great to hear that!

I've confirmed that too, with Preview 1.15.1863.0.

myricam-altas

ricty-atlas

lucida_console-atlas

Yu Gothic is a proportional font according to Wikipedia

Seemingly, yes, that's true.

yugothic

and if that's correct we should probably pick MS Gothic instead:

Or I'd rather suggest that if a user can explicitly set "fallback" font faces, just like CSS font-family, that'd be even better. I think this is already possible e.g. in Visual Studio Code, which has different rendering mechanism, so it may not be straightforward how to introduce such capability to Terminal.

@lhecker
Copy link
Member

lhecker commented Aug 23, 2022

@zadjii-msft We improved box drawing rendering for AtlasEngine in #13549. Should we close this issue now?

@microsoft-github-policy-service microsoft-github-policy-service bot added the In-PR This issue has a related PR label Mar 6, 2023
microsoft-github-policy-service bot pushed a commit that referenced this issue Apr 26, 2023
This is practically a from scratch rewrite of AtlasEngine.

The initial approach used a very classic monospace text renderer, where
the viewport is subdivided into cells and each cell is assigned one
glyph texture, just like how real terminals used to work.
While we knew that it would have problems with overly large glyphs,
like those found in less often used languages, we didn't expect the
absolutely massive number of fonts that this approach would break.
For one, the assumption that monospace fonts are actually mostly
monospace has turned out to be a complete lie and we can't force users
to use better designed fonts. But more importantly, we can't just
design an entire Unicode fallback font collection from scratch where
every major glyph is monospace either. This is especially problematic
for vertical overhangs which are extremely difficult to handle in a
way that outperforms the much simpler alternative approach:
Just implementing a bog-standard, modern, quad-based text renderer.

Such an approach is both, less code and runs faster due to a less
complex CPU-side. The text shaping engine (in our case DirectWrite)
has to resolve text into glyph indices anyways, so using them directly
for text rendering allows reduces the effort of turning it back into
text ranges and hashing those. It's memory overhead is also reduced,
because we can now break up long ligatures into their individual glyphs.
Especially on AMD APUs I found this approach to run much faster.

A list of issues I think are either obsolete (and could be closed)
or resolved with this PR in combination with #14255:

Closes #6864
Closes #6974
Closes #8993
Closes #9940
Closes #10128
Closes #12537
Closes #13064
Closes #13527
Closes #13662
Closes #13700
Closes #13989
Closes #14022
Closes #14057
Closes #14094
Closes #14098
Closes #14117
Closes #14533
Closes #14877

## PR Checklist
* Enabling software rendering enables D2D mode ✅
* Both D2D and D3D:
  * Background appears correctly ✅✅
  * Text appears correctly
    * Cascadia Code Regular ✅✅
    * Cascadia Code Bold ✅✅
    * Cascadia Code Italic ✅✅
    * Cascadia Code block chars leave (almost) no gaps ✅✅
    * Terminus TTF at 13.5pt leaves no gaps between block chars ✅✅
    * ``"`u{e0b2}`u{e0b0}"`` in Fira Code Nerd Font forms a square ✅✅
  * Cursor appears correctly
    * Legacy small/medium/large ✅✅
    * Vertical bar ✅✅
    * Underscore ✅✅
    * Empty box ✅✅
    * Full box ✅✅
    * Double underscore ✅✅
  * Changing the cursor color works ✅✅
  * Selection appears correctly ✅✅
  * Scrolling in various manners always renders correctly ✅✅
  * Changing the text antialising mode works ✅✅
  * Semi-transparent backgrounds work ✅✅
  * Scroll-zooming the font size works ✅✅
  * Double-size characters work ✅✅
  * Resizing while text is printing works ✅✅
  * DWM `+Heatmap_ShowDirtyRegions` shows that only the cursor
    region is dirty when it's blinking ✅✅
* D2D
  * Margins are filled with background color ❌
    They're filled with the neighboring's cell background color for
    convenience, as D2D doesn't support `D3D11_TEXTURE_ADDRESS_BORDER`
* D3D
  * Margins are filled with background color ✅
  * Soft fonts work ✅
  * Custom shaders enable continous redraw if time constant is used ✅
  * Retro shader appears correctly ✅
  * Resizing while a custom shader is running works ✅
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Fonts Related to the font Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Help Wanted We encourage anyone to jump in on these. In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Priority-2 A description (P2) Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants