Characters overlapping when they have changed colo

问题:

As you can see the upper dark X's are cut even though there is space for them.

This happens because they have changed color and are printed backwards (from right to left).

Is this a bug, faulty code, a bad setup on my system or (I doubt it) like it is supposed to be?

Here is the code that generates this output:

#include <Windows.h>
#include <iostream>
void moveTo(int x,int y){
    COORD kord={x,y};
    SetConsoleCursorPosition(GetStdHandle(STD_OUTPUT_HANDLE),kord);
}
void setColor(WORD attributes){
    SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), attributes);
}

void main(){
    for(int i=9;i+1;i--)
    {
        moveTo(i,0);
        std::cout.put('X');
    }
    for(int i=-10;i;i++)
    {
        moveTo(i+10,1);
        std::cout.put('X');
    }
    setColor(8);
    for(int i=9;i+1;i--)
    {
        moveTo(i,2);
        std::cout.put('X');
    }
    for(int i=-10;i;i++)
    {
        moveTo(i+10,3);
        std::cout.put('X');
    }
    setColor(7);
    for(int i=9;i+1;i--)
    {
        moveTo(i,4);
        std::cout.put('X');
    }
    for(int i=-10;i;i++)
    {
        moveTo(i+10,5);
        std::cout.put('X');
    }
    std::cin.get();
}

回答1:

This is a bug in Windows.

As mentioned in the errata by Hans Passant:

I repro too, VS2008 on Win7. Cool bug. Changing the console font fixes it.

Let's use this bug isolation. I recognize this font as Petite Terminal, which implies you both most likely configured this project as a Win32 Console Application. The additional repro with GCC confirms this hypothesis, and we will assume, from a practical standpoint, that all of you were getting a 32-bit console application running inside of a Windows terminal.

The question becomes why it's writing exactly one additional column of pixels in the context of the default terminal font, color 8, and backwards writing into a console screen buffer.

Specifically, let's break this problem up into its component pieces:

1. When a write is issued, a character is written to a location in the terminal array
2. When the default color (7) is selected, pixels do not overflow into other buffers within the array
3. When color 8 is selected, an additional column of pixels is written to the next region of the buffer, which is only visible when the text is recited backwards

Because of the presence of overspill in (3), this is a bug.

Quoting Raymond Chen:

The console rendering model assumes each character fits neatly inside its fixed-sized cell. When a new character is written to a cell, the old cell is overprinted with the new character, but if the old character has overhang or underhang, those extra pixels are left behind since they "spilled over" the required cell and infected neighbor cells. Similarly, if a neighboring character "spilled over", those "spillover pixels" would get erased.

The set of fonts that could be used in the console window was trimmed to the fonts that were tested and known to work acceptably in console windows. For English systems, this brought us down to Lucida Console and Terminal.

...

"Well, that's stupid. You should've stopped me from choosing a font that so clearly results in nonsense."

And that's what we did.

Not that I'm blaming Raymond on this one, but he authoritatively illustrates this as a "can't happen."

The selection and testing of console fonts for Windows should have caught this. The fact that it's even an issue at all is an aberration.