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.

Sign up for GitHub

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

Jump to bottom

Emoji character width / spacing too large (Black Medium Square) #5910

Closed
R-Broadley opened this issue May 14, 2020 · 1 comment · Fixed by #5914
Closed

Emoji character width / spacing too large (Black Medium Square) #5910

R-Broadley opened this issue May 14, 2020 · 1 comment · Fixed by #5914
Labels
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 Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.

Comments

@R-Broadley
Copy link

Environment

Windows Version: 10.0.18362.836
Terminal Version: 0.11.1333.0

Steps to reproduce

Paste the following into the terminal (command prompt or WSL): ◼◼◼◼◼◼◼◼◼

Expected behavior

The characters are normally spaced. Screen shot is from Version: 0.11.1251.0.
This has been the previous behaviour and is how other terminals (tested in gnome-terminal) display the same setup.
block_spacing_correct

Actual behavior

The characters are too wide / too much spacing between them and this breaks the layout where mono fonts are expected and relied upon for layout.
Screenshot is from Version: 0.11.1333.0.
block_spacing_bug
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels May 14, 2020
@DHowett-MSFT
Copy link
Contributor

So, I've got to admit. I sorta hate this 😄

We knew there'd be some regressions when we recategorized some of the codepoints as "wide", but like, I'm at a loss for what to do with this one.

Everything I can find about these two glyphs indicates that we're supposed to give them Emoji treatment.

From the Unicode Character Database (latest version):

PS> $chs=($ucd.ucd.repertoire.char | ? cp -in ("25FB", "25FC"))
PS> $chs | ft cp,ea,Emoji,ExtPict

cp   ea Emoji ExtPict
--   -- ----- -------
25FB N  Y     Y
25FC N  Y     Y

Perhaps the answer lies in emoji-sequences.txt? The emoji whose emoji presentations require U+FE0F might be good candidates for reshrinking?

DHowett-MSFT pushed a commit that referenced this issue May 14, 2020
@DHowett
Reclassify U+25FB, U+25FC as Narrow
7d79f3c 
This seems to be in line with the emoji-sequences table in the latest
version of the unicode standard: those glyphs require U+FE0F to activate
their emoji presentation. Since we don't support composing U+FE0F, we
should not present them as emoji by default.

Fixes #5910.
@DHowett-MSFT DHowett-MSFT mentioned this issue May 14, 2020
Merged
@ghost ghost added the In-PR This issue has a related PR label May 14, 2020
@ghost ghost closed this as completed in #5914 May 14, 2020
@ghost ghost removed the In-PR This issue has a related PR label May 14, 2020
ghost pushed a commit that referenced this issue May 14, 2020
@DHowett
CodepointWidthDetector: reclassify U+25FB, U+25FC as Narrow (#5914)
c39f9c6 
This seems to be in line with the emoji-sequences table in the latest
version of the Unicode standard: those glyphs require U+FE0F to activate
their emoji presentation. Since we don't support composing U+FE0F, we
should not present them as emoji by default.

Fixes #5910.

Yes, I hate this.
@ghost ghost added the Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. label May 14, 2020
DHowett-MSFT pushed a commit that referenced this issue May 14, 2020
@DHowett
CodepointWidthDetector: reclassify U+25FB, U+25FC as Narrow (#5914)
09f02df 
This seems to be in line with the emoji-sequences table in the latest
version of the Unicode standard: those glyphs require U+FE0F to activate
their emoji presentation. Since we don't support composing U+FE0F, we
should not present them as emoji by default.

Fixes #5910.

Yes, I hate this.

(cherry picked from commit c39f9c6)
jelster pushed a commit to jelster/terminal that referenced this issue May 28, 2020
@DHowett @jelster
CodepointWidthDetector: reclassify U+25FB, U+25FC as Narrow (microsof…
118c087 
…t#5914)

This seems to be in line with the emoji-sequences table in the latest
version of the Unicode standard: those glyphs require U+FE0F to activate
their emoji presentation. Since we don't support composing U+FE0F, we
should not present them as emoji by default.

Fixes microsoft#5910.

Yes, I hate this.
@github-actions github-actions bot mentioned this issue Mar 9, 2024
Closed
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
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 Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

CodepointWidthDetector: reclassify U+25FB, U+25FC as Narrow microsoft/terminal
2 participants
@DHowett-MSFT @R-Broadley