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

Block Elements not rendering correctly with AtlasEngine enabled #14098

Closed
Dan-Albrecht opened this issue Sep 28, 2022 · 5 comments · Fixed by #14099 or #14959
Closed

Block Elements not rendering correctly with AtlasEngine enabled #14098

Dan-Albrecht opened this issue Sep 28, 2022 · 5 comments · Fixed by #14099 or #14959
Assignees
Labels
Area-AtlasEngine In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-3 A description (P3) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.

Comments

@Dan-Albrecht
Copy link
Member

Windows Terminal version

1.16.2642.0

Windows build number

10.0.22000.0

Other Software

No response

Steps to reproduce

In PowerShell with the default Cascadia Mono font, run: Write-Host "`u{2595}`u{2594}`n`u{2595}`u{2581}"

Expected Behavior

In version 1.15.2525.0 or 1.16.2642.0 with AtlasEngine disabled:
image

Actual Behavior

The top is cut off:
image

@Dan-Albrecht Dan-Albrecht added 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 labels Sep 28, 2022
@Dan-Albrecht
Copy link
Member Author

Dan-Albrecht commented Sep 28, 2022

Might be same underlying issue as #14022

@lhecker lhecker self-assigned this Sep 28, 2022
@lhecker
Copy link
Member

lhecker commented Sep 28, 2022

Note to self/team: The block character scaling technique in _getCachedGlyphLayout is inherently flawed as I realized yesterday. What it does is:

  • Get the glyph's advance width/height
  • Resize to match the cell size

This doesn't work with fonts that use side bearings for block characters. A better way would be to assume that all fonts that define any block character also probably define the U+2588 Full Block character. That way we can do:

  • Get the font's full block glyph
  • Get the actual size including side bearings of the full block
  • Resize to match the cell size but apply the scale to the given glyph instead

@lhecker lhecker added Product-Terminal The new Windows Terminal. Priority-3 A description (P3) labels Sep 29, 2022
@ghost ghost added the In-PR This issue has a related PR label Sep 29, 2022
@carlos-zamora carlos-zamora added this to the Terminal v1.17 milestone Sep 30, 2022
@carlos-zamora carlos-zamora removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Sep 30, 2022
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label Sep 30, 2022
@lhecker lhecker removed this from the Terminal v1.17 milestone Oct 12, 2022
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Oct 12, 2022
@ghost ghost closed this as completed in #14099 Oct 17, 2022
ghost pushed a commit that referenced this issue Oct 17, 2022
This commit makes the following improvements:
* Only adjust block characters that come from fallback fonts. This ensures
  that the glyphs of the chosen font all look exactly as they were designed.
* When adjusting the size, use the fallback font's full block glyph U+2588
  to determine the size that the given glyph should have.

Closes #14098

## Validation Steps Performed
* Print `UTF-8-demo.txt` in Consolas.
* All block glyphs look uniform. ✅
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Oct 17, 2022
@Dan-Albrecht
Copy link
Member Author

Dan-Albrecht commented Oct 19, 2022

@lhecker, while I agree your change is correctly called righer-er, I think we need a even-more-righter followup as my issue is not resolved. I'm built from source at bfd480b. U+2594 seems to be causing problems and doesn't seem to be in the torture test.

Write-Host "`u{2595}`u{2594}`n`u{2595}`u{2581}"
Write-Host "`nXXX`n`u{2594}`nXXX`n"

Atlas Off:
image

Atlas On:
image

@lhecker lhecker reopened this Oct 19, 2022
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label Oct 19, 2022
@lhecker
Copy link
Member

lhecker commented Oct 19, 2022

@Dan-Albrecht Somewhat "late" in the development cycle I changed the algorithm so that it doesn't touch characters found in the given user font. My intention was that glyphs in the user's font remain untouched. If we don't do that this leads to other display issues (incorrect alginment, etc.). U+2594 is part of Cascadia Mono and so it won't get "adjusted" to fit the cell and I forgot to re-test it as part of the PR, focusing only on Consolas, etc.

Not sure what to do about this issue now: I should try to see if it helps to round up ascend/descend after all. But I'm not certain we can merge that - people have complained in the past when I did that. Otherwise we'll either have to wait for the next big AtlasEngine update which brings support for overlapping glyphs, or support for line height adjustments (which I'm submitting tomorrow).

DHowett pushed a commit that referenced this issue Dec 1, 2022
This commit makes the following improvements:
* Only adjust block characters that come from fallback fonts. This ensures
  that the glyphs of the chosen font all look exactly as they were designed.
* When adjusting the size, use the fallback font's full block glyph U+2588
  to determine the size that the given glyph should have.

Closes #14098

## Validation Steps Performed
* Print `UTF-8-demo.txt` in Consolas.
* All block glyphs look uniform. ✅

(cherry picked from commit 97abc3d)
Service-Card-Id: 86159056
Service-Version: 1.16
@ghost
Copy link

ghost commented Dec 14, 2022

🎉This issue was addressed in #14099, which has now been successfully released as Windows Terminal Preview v1.16.3463.0 and v1.16.3464.0.:tada:

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-AtlasEngine In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-3 A description (P3) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
3 participants