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

Incorrect full-width char rendering #17016

Closed
xiongnemo opened this issue Apr 4, 2024 · 5 comments
Closed

Incorrect full-width char rendering #17016

xiongnemo opened this issue Apr 4, 2024 · 5 comments
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Attention The core contributors need to come back around and look at this ASAP. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting

Comments

@xiongnemo
Copy link

xiongnemo commented Apr 4, 2024

Windows Terminal version

1.19.10821.0

Windows build number

10.0.19045.0

Other Software

SonicLair.Cli@1.2.0 which uses:
Terminal.Gui@1.6.4
Font is attached:
Sarasa Term SC Light Nerd Font Complete.zip

Steps to reproduce

Fire up an application with Terminal.GUI which renders full-width characters using a monospaced font.

I calculate what's the actual length the terminal should render, which shouldn't be the problem:

SonicLair.Cli/Tools/StringExtension.cs

namespace SonicLair.Cli.Tools
{
    public static class StringExtension
    {
        public static int StandardizedStringLength(this string input)
        {
            // each CJK rune is 2 letter width when using a monospaced font
            int length = 0;
            foreach (var c in input)
            {
                length += Rune.IsWideChar(c) ? 2 : 1;
            }
            return length;
        }
        public static string RunePadRight(this string stringToPad, int totalWidth, char paddingChar = ' ')
        {
            int standardizedStringLength = stringToPad.StandardizedStringLength();
            if (standardizedStringLength >= totalWidth)
            {
                return stringToPad;
            }
            return stringToPad.PadRight(totalWidth - (standardizedStringLength - stringToPad.Length), paddingChar);
        }
        public static string RunePadLeft(this string stringToPad, int totalWidth, char paddingChar = ' ')
        {
            int standardizedStringLength = stringToPad.StandardizedStringLength();
            if (standardizedStringLength >= totalWidth)
            {
                return stringToPad;
            }
            return stringToPad.PadLeft(totalWidth - (standardizedStringLength - stringToPad.Length), paddingChar);
        }
    }
}

Expected Behavior

This is a screenshot at 1.19.10302.0:
image

This is a screenshot using Windows's terminal:
image

Actual Behavior

This is a screenshot at 1.19.10821.0:
image

It can be inferred that wt renders three instead of two single-char-width when rendering full-width characters.
Also, the first line is missing. I'm not quite sure whether this is related...
P.S. AtlasEngine is enabled for both versions

@xiongnemo xiongnemo 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 Apr 4, 2024

This comment was marked as off-topic.

@lhecker
Copy link
Member

lhecker commented Apr 4, 2024

This is a screenshot using Windows's terminal:

That's the old "conhost", also known as "Console Window Host" or similar names. Windows Terminal is only the application with tabs.

However, that screenshot is excellent because it reveals what is going on. If you zoom in you can see how after each wide character you have a weird glyph:
image

I believe you're accidentally writing "garbage" / invalid characters into your output. So far we just happened to ignore them but it seems that now we don't. I think this may be caused by #16825 which was an intentional change.

Could you check with a debugger what characters you're actually writing to the console / terminal? It'd be nice if you could post them here or send us a screenshot!

@lhecker lhecker added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Apr 4, 2024
@j4james
Copy link
Collaborator

j4james commented Apr 4, 2024

See also gui-cs/Terminal.Gui#2928

@xiongnemo
Copy link
Author

xiongnemo commented Apr 4, 2024

That's the old "conhost", also known as "Console Window Host" or similar names. Windows Terminal is only the application with tabs.

Thanks for the clarify!

I created a demo project using Terminal.GUI and set one label to some CJK chars:

dotnet new --install Terminal.Gui.templates
dotnet new tui -n myproj
cd myproj

myproj/MyView.Designer.cs:

...
this.label1.Text = "こんにちは";
...
dotnet run

Here's the screenshot:
image

As I dig into issues with that library I found gui-cs/Terminal.Gui#2943 and gui-cs/Terminal.Gui#2928. It seems this is an ongoing issue on their side.

Directly running their demo produces the same result:

image

Could you check with a debugger what characters you're actually writing to the console / terminal?

I'm not quite familiar with that library's underlying mechanics, so I will open an issue in their repo and close this for now. If there's further issue addressed with wt I will reopen it and add new comments.

Thank you for your time and effort in helping me locate the real issue!

@microsoft-github-policy-service microsoft-github-policy-service bot added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Apr 4, 2024
@xiongnemo
Copy link
Author

See also gui-cs/Terminal.Gui#2928

Yes I'm looking into it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Attention The core contributors need to come back around and look at this ASAP. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting
Projects
None yet
Development

No branches or pull requests

3 participants