When the terminal is shrunk to a very small size, the "\033[" escape sequence is not fully displayed. #23649

Closed
opened 2026-01-31 08:48:11 +00:00 by claunia · 5 comments
Owner

Originally created by @YXPHOPE on GitHub (Sep 27, 2025).

Windows Terminal version

1.24.250825002-preview

Windows build number

10.0.19045.0

Other Software

nbcmdio==1.8.62

Steps to reproduce

  1. pip install nbcmdio==1.8.62
  2. Prepare a normal image file, path: E:/img.png
  3. run the following code:
from nbcmdio import prt, NbCmdIO

NbCmdIO()
img_path = "E:/img.png"
prt.drawImage(img_path)    # RGB
prt.drawImageStr(img_path) # gray
prt.drawHGrad((255, 0, 0), (0, 255, 255), prt.size_col)
prt.drawHGrad((0, 255, 0), (255, 0, 255), prt.size_col)
  1. Pinch with two fingers (or press Ctrl+-) to shrink the terminal, and the terminal size will get greater, then run the program again until the terminal is reduced to a specific size (mine is row=127, col=469) to reproduce the issue.

Expected Behavior

When the terminal is not significantly reduced in size, the image can be displayed completely and correctly (as shown in the figure below).

Image

Actual Behavior

Image

The image is displayed by the drawImage method generating a large number of escape sequences "\033[38;2;fr;fg;fbm\033[48;2;br;bg;bbm▄", where (fr, fg, fb) represents the foreground RGB color and (br, bg, bb) represents the background RGB color. However, when displaying the image, incomplete rendering occurs. The edges appear uneven but remain consistently reproducible.1

Interestingly, the gradient color strip generated by drawHGrad (consisting of numerous "\033[48;2;br;bg;bbm ") displays normally. The only differences are the absence of the foreground escape sequence and the replacement of "▄" with a space " ".

Image
Originally created by @YXPHOPE on GitHub (Sep 27, 2025). ### Windows Terminal version 1.24.250825002-preview ### Windows build number 10.0.19045.0 ### Other Software nbcmdio==1.8.62 ### Steps to reproduce 1. pip install nbcmdio==1.8.62 2. Prepare a normal image file, path: `E:/img.png` 3. run the following code: ```python from nbcmdio import prt, NbCmdIO NbCmdIO() img_path = "E:/img.png" prt.drawImage(img_path) # RGB prt.drawImageStr(img_path) # gray prt.drawHGrad((255, 0, 0), (0, 255, 255), prt.size_col) prt.drawHGrad((0, 255, 0), (255, 0, 255), prt.size_col) ``` 4. Pinch with two fingers (or press Ctrl+-) to shrink the terminal, and the terminal size will get greater, then run the program again until the terminal is reduced to a specific size (mine is row=127, **col=469**) to reproduce the issue. ### Expected Behavior When the terminal is not significantly reduced in size, the image can be displayed completely and correctly (as shown in the figure below). <img width="1470" height="1042" alt="Image" src="https://github.com/user-attachments/assets/d52a5d9c-6e28-4fe3-8aa2-3872de00798e" /> ### Actual Behavior <img width="1470" height="1042" alt="Image" src="https://github.com/user-attachments/assets/06799427-ae1b-4967-956d-8f6f3e5ab315" /> The image is displayed by the `drawImage` method generating a large number of escape sequences `"\033[38;2;fr;fg;fbm\033[48;2;br;bg;bbm▄"`, where `(fr, fg, fb)` represents the foreground RGB color and `(br, bg, bb)` represents the background RGB color. However, when displaying the image, **incomplete rendering** occurs. The **edges appear uneven** but remain consistently reproducible.1 Interestingly, the gradient color strip generated by `drawHGrad` (consisting of numerous `"\033[48;2;br;bg;bbm "`) displays normally. The only differences are the absence of the foreground escape sequence and the replacement of `"▄"` with a space `" "`. <img width="1470" height="374" alt="Image" src="https://github.com/user-attachments/assets/300db58c-f9ff-4322-bc15-cc0eacbb0abd" />
claunia added the Needs-TriageIssue-BugNeeds-Author-FeedbackNo-Recent-Activity labels 2026-01-31 08:48:11 +00:00
Author
Owner

@DHowett commented on GitHub (Oct 1, 2025):

Honestly no idea where to start here 😅

To help us diagnose... if you replace with x, does it fail in the same way?

I originally thought you weren't enabling ENABLE_VIRTUAL_TERMINAL_PROCESSING, but it looks like you definitely are:

4d46818713/nbcmdio/output.py (L94)

@DHowett commented on GitHub (Oct 1, 2025): Honestly no idea where to start here 😅 To help us diagnose... if you replace `▄` with `x`, does it fail in the same way? I originally thought you weren't enabling `ENABLE_VIRTUAL_TERMINAL_PROCESSING`, but it looks like you definitely are: https://github.com/YXPHOPE/NbCmdIO/blob/4d468187138cce5a3b22daf438992c5ce6413a82/nbcmdio/output.py#L94
Author
Owner

@YXPHOPE commented on GitHub (Oct 2, 2025):

Still the same after remove kernel32.SetConsoleMode(kernel32.GetStdHandle(-11), 7) .

Also occurs in cmd, powershell on windows.

@YXPHOPE commented on GitHub (Oct 2, 2025): Still the same after remove `kernel32.SetConsoleMode(kernel32.GetStdHandle(-11), 7)` . Also occurs in cmd, powershell on windows.
Author
Owner

@YXPHOPE commented on GitHub (Oct 3, 2025):

I see. There's a length limit in the terminal, likely the buffer size, where a maximum of 16383(=0xffff // 4) characters can be written at once—anything beyond that gets half truncated. You can test this by running sys.stdout.write('a'*16373+'b'*10) and sys.stdout.write('a'*16374+'b'*10). In my case, each pixel \033[48;2;255;255;255m\033[38;2;255;255;255m▄ can be up to 40 characters long, col 476 * 40 = 19040, so only half of it can be printed.

Solution: split the string by chunk_size < 16383, and print the chunk one by one.

By the way, how to change this 16383 restriction?

@YXPHOPE commented on GitHub (Oct 3, 2025): I see. There's a length limit in the terminal, likely the buffer size, where a maximum of **16383**(=0xffff // 4) characters can be written at once—anything beyond that gets half truncated. You can test this by running `sys.stdout.write('a'*16373+'b'*10)` and `sys.stdout.write('a'*16374+'b'*10)`. In my case, each pixel `\033[48;2;255;255;255m\033[38;2;255;255;255m▄` can be up to 40 characters long, col `476` * `40` = 19040, so only half of it can be printed. **Solution**: split the string by chunk_size < 16383, and print the chunk one by one. By the way, how to change this 16383 restriction?
Author
Owner

@DHowett commented on GitHub (Oct 6, 2025):

Ah, fascinating!

The console subsystem does not have such a limit. A C application performing the same work results in the correct behavior:

#define WIN32_LEAN_AND_MEAN
#define UNICODE
#include <windows.h>
#include <stdlib.h>

int main(int argc, char** argv) {
        int len = 16385;
        if(argc > 1)
                len = atoi(argv[1]);
        wchar_t* buffer = malloc(len * sizeof(wchar_t));
        for(int i = 0; i < len - 1; ++i)
                buffer[i] = L'a';
        buffer[len-1] = L'b';
        buffer[len] = L'\0';
        WriteConsoleW(GetStdHandle(STD_OUTPUT_HANDLE),
                buffer,
                len,
                NULL,
                NULL);
        return 0;
}

(should emit one b at the end of a len-length buffer.)

Image

I suspect this points to a limitation in the Python runtime. If you need to change it or file a bug report about it, you may need to dig deeper to figure out exactly where it is.

@DHowett commented on GitHub (Oct 6, 2025): Ah, fascinating! The console subsystem does not have such a limit. A C application performing the same work results in the correct behavior: ```c #define WIN32_LEAN_AND_MEAN #define UNICODE #include <windows.h> #include <stdlib.h> int main(int argc, char** argv) { int len = 16385; if(argc > 1) len = atoi(argv[1]); wchar_t* buffer = malloc(len * sizeof(wchar_t)); for(int i = 0; i < len - 1; ++i) buffer[i] = L'a'; buffer[len-1] = L'b'; buffer[len] = L'\0'; WriteConsoleW(GetStdHandle(STD_OUTPUT_HANDLE), buffer, len, NULL, NULL); return 0; } ``` (should emit one `b` at the end of a `len`-length buffer.) <img width="1812" height="1528" alt="Image" src="https://github.com/user-attachments/assets/938d3f44-5aa7-44f6-abea-cdbfb227caa8" /> I suspect this points to a limitation in the Python runtime. If you need to change it or file a bug report about it, you may need to dig deeper to figure out exactly where it is.
Author
Owner

@microsoft-github-policy-service[bot] commented on GitHub (Oct 10, 2025):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@microsoft-github-policy-service[bot] commented on GitHub (Oct 10, 2025): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**. <!-- Policy app identification https://img.shields.io/static/v1?label=PullRequestIssueManagement. -->
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#23649