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

Italics are not rendered for terminal programs such as Neovim #5461

Closed
edyu opened this issue Apr 22, 2020 · 14 comments · Fixed by #8580
Closed

Italics are not rendered for terminal programs such as Neovim #5461

edyu opened this issue Apr 22, 2020 · 14 comments · Fixed by #8580
Labels
Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Issue-Task It's a feature request, but it doesn't really need a major design. Needs-Tag-Fix Doesn't match tag requirements Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.

Comments

@edyu
Copy link

edyu commented Apr 22, 2020

Environment

Windows build number: 10.0.19608.0
Windows Terminal version (if applicable): 0.10

Any other software? Neovim and WSL2

Steps to reproduce

I have neovim installed on wsl2 and when I have configured neovim to render italics for comments. However, italics are not rendered when I use neovim when I run it in terminal mode in the windows terminal. I know that it's not a neovim problem because if I run it on alacritty for example, the comments are rendered in italics. I'm running neovim under WSL2 but I don't think it has any effect to this.

Expected behavior

Italics should render properly on the terminal.

Actual behavior

Italics are being ignored when rendering and fonts are only rendering in the "regular" style.

@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 Apr 22, 2020
@jdebp
Copy link

jdebp commented Apr 22, 2020

One does not need WSL or NeoVIM to reproduce this . Attributes.ps1 will do, and indicates the currently missing SGR support.

@zadjii-msft
Copy link
Member

That's right, we probably should add support for italics at some point in the future.

@zadjii-msft zadjii-msft added Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Issue-Task It's a feature request, but it doesn't really need a major design. Product-Terminal The new Windows Terminal. labels Apr 23, 2020
@zadjii-msft zadjii-msft added this to the Terminal Backlog milestone Apr 23, 2020
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Apr 23, 2020
@DHowett-MSFT DHowett-MSFT removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Apr 23, 2020
@DHowett-MSFT
Copy link
Contributor

Yep, we should add support for italic and faint and ~ ~ bold ~ ~ (don't ask, it's complicated).

DHowett pushed a commit that referenced this issue Jul 1, 2020
This is essentially a rewrite of the
`TerminalDispatch::SetGraphicsRendition` method, bringing it into closer
alignment with the `AdaptDispatch` implementation, simplifying the
`ITerminalApi` interface, and making the code easier to extend. It adds
support for a number of attributes which weren't previously implemented.

REFERENCES

* This is a mirror of the `AdaptDispatch` refactoring in PR #5758.
* The closer alignment with `AdaptDispatch` is a small step towards
  solving issue #3849.
* The newly supported attributes should help a little with issues #5461
  (italics) and #6205 (strike-through).

DETAILS

I've literally copied and pasted the `SetGraphicsRendition`
implementation from `AdaptDispatch` into `TerminalDispatch`, with only
few minor changes:

* The `SetTextAttribute` and `GetTextAttribute` calls are slightly
  different in the `TerminalDispatch` version, since they don't return a
  pointless `success` value, and in the case of the getter, the
  `TextAttribute` is returned directly instead of by reference.
  Ultimately I'd like to move the `AdaptDispatch` code towards that way
  of doing things too, but I'd like to deal with that later as part of a
  wider refactoring of the `ConGetSet` interface.
* The `SetIndexedForeground256` and `SetIndexedBackground256` calls
  required the color indices to be remapped in the `AdaptDispatch`
  implementation, because the conhost color table is in a different
  order to the XTerm standard. `TerminalDispatch` doesn't have that
  problem, so doesn't require the mapping.
* The index color constants used in the 16-color `SetIndexedForeground`
  and `SetIndexedBackground` calls are also slightly different for the
  same reason.

VALIDATION

I cherry-picked this code on top of the #6506 and #6698 PRs, since
that's only way to really get the different color formats passed-through
to the terminal. I then ran a bunch of manual tests with various color
coverage scripts that I have, and confirmed that all the different color
formats were being rendered as expected.

Closes #6725
@rashil2000
Copy link
Contributor

Italics is a very important missing feature, I feel. Alacritty supports it (@edyu mentions this). Even ConEmu supports this (and ConEmu is really old).

Cheers!

@DHowett
Copy link
Member

DHowett commented Sep 16, 2020

Thanks for letting us know. In the future, you can register your support for an issue by using the 👍 button (or the Reactions) button if that button is not available.

@mowestusa
Copy link

I did +1 this feature request, because I have observed this same behavior with the vim syntax highlighting of markdown. Vim comes out of the box configured to display for markdown files italics, bold, and bold/italics which I find very handy when I have large blocks of text written in markdown and I'm doing edits in the terminal. I'm loving using Ubuntu 20.04 in WSL 2 inside of Windows Terminal, but this one feature would be a huge quality of life improvement when you spend hours of your day editing markdown text in the terminal. Thanks for considering this feature, and thanks for the work that developers have already done on Windows Terminal.

@ghost ghost added the In-PR This issue has a related PR label Dec 13, 2020
DHowett pushed a commit that referenced this issue Dec 18, 2020
This PR adds support for the ANSI _italic_ graphic rendition attribute,
which is enabled by the `SGR 3` escape sequence.

For the GDI renderer, I've just created an additional italic variant of
the font, and then the `UpdateDrawingBrushes` method selects the
appropriate font variant into the device context based on the requested
text attributes.

It's a bit more complicated in the DX renderer, because we need both an
italic variant of the font, and a variant of the text format object. The
`CustomTextLayout` class also had to be updated to hold the two font and
format instances, and decide which of the variants to use based on a
`useItalicFont` property in the drawing context, initially set in the
`UpdateDrawingBrushes` method.

## Validation Steps Performed
I've created some test content using a range of different character sets
(e.g. CJK, block characters, emoji, etc.), then applied the italic
attribute mixed with various other SGR attributes to see how they
interact. The output isn't always perfect, but I think it seems
reasonable given the constraints of a cell-based terminal renderer.

Closes #5461
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. Needs-Tag-Fix Doesn't match tag requirements and removed In-PR This issue has a related PR labels Dec 18, 2020
@haininhhoang94
Copy link

since we already fixed/improve the issues, when will the next release include this commit (for either Release and Preview?

@DHowett
Copy link
Member

DHowett commented Jan 6, 2021

The next release will include this commit when it comes out.

mpela81 pushed a commit to mpela81/terminal that referenced this issue Jan 28, 2021
)

This PR adds support for the ANSI _italic_ graphic rendition attribute,
which is enabled by the `SGR 3` escape sequence.

For the GDI renderer, I've just created an additional italic variant of
the font, and then the `UpdateDrawingBrushes` method selects the
appropriate font variant into the device context based on the requested
text attributes.

It's a bit more complicated in the DX renderer, because we need both an
italic variant of the font, and a variant of the text format object. The
`CustomTextLayout` class also had to be updated to hold the two font and
format instances, and decide which of the variants to use based on a
`useItalicFont` property in the drawing context, initially set in the
`UpdateDrawingBrushes` method.

## Validation Steps Performed
I've created some test content using a range of different character sets
(e.g. CJK, block characters, emoji, etc.), then applied the italic
attribute mixed with various other SGR attributes to see how they
interact. The output isn't always perfect, but I think it seems
reasonable given the constraints of a cell-based terminal renderer.

Closes microsoft#5461
@Leandros
Copy link

Is it possible to disable italics, in case my font doesn't support any italics?

@j4james
Copy link
Collaborator

j4james commented Dec 30, 2021

Not in the terminal, but the application that's requesting the italics may have an option for that. In Neovim I think it's controlled by the color scheme.

@bryant-the-coder
Copy link

bryant-the-coder commented Jan 7, 2022

my italics is being cut off at the end of each letter. what should i do?

@zadjii-msft
Copy link
Member

@k1ng440
Copy link

k1ng440 commented Sep 5, 2022

Its been 2 years still no fix :(

@zadjii-msft
Copy link
Member

@k1ng440 Italics support was added nearly two years ago: #8580. What specifically "has no fix"? The "italics get cut off some times" issue? That's tracked over in #9381

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Issue-Task It's a feature request, but it doesn't really need a major design. Needs-Tag-Fix Doesn't match tag requirements 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
Development

Successfully merging a pull request may close this issue.