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

24 bits ANSI codes are wrongly converted instead of being stripped #217

Open
Delgan opened this issue Mar 17, 2019 · 5 comments · May be fixed by #222
Open

24 bits ANSI codes are wrongly converted instead of being stripped #217

Delgan opened this issue Mar 17, 2019 · 5 comments · May be fixed by #222

Comments

@Delgan
Copy link
Contributor

Delgan commented Mar 17, 2019 •
edited

Hi.

Some terminals support 24-bit ANSI colors (aka "true colors") in the form ESC[ 38;2;<r>;<g>;<b>.

This code:

import colorama
colorama.init()
print("\x1b[38;2;166;226;46m{}\x1b[0m".format("Foo"))

Result on Windows:

1552843793-screenshot

Result on a true colors terminal:

1552844028-screenshot

I guess there may be an issue within the colorama regex in charge of parsing color codes. On Windows, this should be stripped, right?
@SeaHOH
Copy link

SeaHOH commented Mar 23, 2019 •
edited

colorama/colorama/ansitowin32.py

Lines 224 to 225 in d7a5382

if command == 'm':
for param in params:

Need limit this params tuple lenght to 2, just like below:

        if command == 'm':
-            for param in params:
+            for param in params[:2]:

Or ignore whole params which the first param not included in AnsiCodes.

@wiggin15
Copy link
Collaborator

@Delgan you are correct, it should be stripped.
Due to the nature of the CSI 'm' (color) command, multiple codes can be specified in the same command. This is why we have a for loop going over all the parameters given and treating each parameter as its own code. It just so happens that the RGB you specified has number 46 which is the Back.CYAN code so we read it as such. You can swap out the RGB command (38) with any unrecognized number and the output will be the same, and if you swap the "RGB" number 46 with any other code it will print out that code.
The only idea I have for how to fix this is to explicitly check for parameter "38" and then skip the following 3 parameters.

@Delgan
Copy link
Contributor Author

Delgan commented Mar 31, 2019

Thanks for the explanation @wiggin15, this is indeed what I understood while reading the code.

About the fix, as you and @SeaHOH suggested, I guess it's more explicit to skip the win32 calls if param == 38, rather than slicing the params.

@Delgan Delgan linked a pull request May 25, 2019 that will close this issue
Open
@pfmoore pfmoore mentioned this issue Jan 27, 2020
Closed
@H4CKY54CK H4CKY54CK mentioned this issue Oct 10, 2020
Closed
@MapleCCC
Copy link

Encounter this issue today when using tqdm (tqdm/tqdm#678). Any progress to the fix? I see that @Delgan makes a Pull Request and awaits merge. Could anyone with the merge right kindly do the favour please? It would be highly appreciated. 🙈

@optionsx
Copy link

how can i use this with tqdm?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix special ansi sequences not ignored and producing wrong colors Delgan/colorama
5 participants
@wiggin15 @Delgan @SeaHOH @MapleCCC @optionsx