[FULLY FIXED!] Bugs with rendering HEX view of a file

[AntonyD]

Pls, load this file https://www.upload.ee/files/18660981/exif_ru.lng.html
Open with Lister in a mode #3, set encoding to 65001 (UTF-8)
And you will see such picture: Image: https://i.ibb.co/4gWqsByn/1.png
But instead of you must see this: Image: https://i.ibb.co/NgGz6dY7/2.png
Of course I am talking only about view of Russian words on a right text panel.
Lister obviously has a problem with rendering of 2-bytes symbols for UTF-8.
Looks like rendering process expects ONLY single-byte char representation at input...

For example I decided to select this: Image: https://i.ibb.co/Nw0SRXT/3.png
And after "Copy As Text" command execution I've got only this in a clipboard: "Ширина из�"
So even copy procedure expects single-byte chars. And OF course we have a problem here!
Coz a real selection should be like this: Image: https://i.ibb.co/nMqM44Wx/4.png
Because I wanted to select words - "Ширина изобра" - on a right text panel!
So obviously Lister also has a problem with a proper selection of real bytes.

[ghisler(Author)]

Sorry, not much I can do there - the character stretches over 2 lines, so it gets broken up.

[AntonyD]

IMHO, I described TWO bugs in the topic. One is simply characters rendering. And it seems you didn't say anything at all about this point.
But I will try))) It seems that in the picture from another application it is shown very clearly how to render text data in this right panel.
Just repeat this method: It is clearly visible that two character spaces are used for one symbol. Right now Lister shows wrong text.
In other words, Lister is lying when it displays this human-radable text in the HEX form shown in the accompanying post images.
And you can't fix it?

The second is an incorrect copy result. And Do you want to say that there is no way to make copying correct either, just because line gets broken up?

IF the answer to both questions is NO, then a third question arises - what is the point of even trying to support display in this mode if you cannot support it correctly? Then remove this mode so that it is clear that for such functionality we will have to resort to third-party utilities.
This way it will be fair and, most importantly, correct!

https://i.ibb.co/4gZb8yyG/TC-bug.png
another view on a bug state...
https://i.ibb.co/Nw0SRXT/3.png = This is the very link referred to in the quoted first post in the text on the previous picture.

[ghisler(Author)]

This should be fixed in Total Commander 11.57 beta 1, please check it!

13.10.25 Fixed: Lister, Hex view: Show multi-byte characters split over two lines at the end of the first line (32/64)
and also:
15.02.26 Added: Lister, hex/binary view: wincmd.ini [Lister] set ReplaceWrongWidthChars to 0 to disable the replacement of wrong width characters with dots (32/64)
15.02.26 Fixed: Lister, hex view: Selected text width could be different from not selected text width when characters had other than the default width in fixed width font (32/64)
15.02.26 Fixed: Lister, hex view: Starting selection by holding mouse down to the left of the hexadecimal values would result in wrong start position (32/64)

[AntonyD]

I'm not sure I understand exactly which part of the described problem situation you solved in which version of the described commits
in the quote from the changelog.
BUT I can definitely highlight the following points: Now the selection of letters / words coincides with what can be obtained in Prof.
hex editors. The selection in the hex-codes on the left side coincides with the selection of the characters themselves on the right panel.
Now copying the data gives in the buffer exactly the characters that were highlighted (here of course it means copying just text - that is
readable characters fall into the buffer of course). And that's all fine.
BUT what I still don't understand is the principle of working with a multi-byte character representation.

Let's take the lowercase letter "з" - its UTF-8 representation is D0 B7.
In Prof. hex editors when the first byte is selected only the "void" preceding the actual representation of the character itself
is drawn and shown. Thus we clearly understand that we are dealing with a multi-byte character representation.
Image: https://i.ibb.co/jZgBx81Q/2026-02-26-003816.png
And only and IF we will select the second byte from the pair "D0 B7" we will get the finally expected selection of a real letter "з":
Image: https://i.ibb.co/nMgRZbdM/2026-02-26-003837.png

I can understand that you didn't decide to follow such a strategy of general character rendering and in the visual (symbolic)
right panel all associated readable glyphs of chars your code is printing as "merged". So be it. But why the allocation exactly
the first part from the two-byte representation of a character you take as the fact of selection of the corresponding
character on the right?
Image: https://i.ibb.co/zTh0nkzY/2026-02-26-004335.png
I would really ask you to pay attention to this discrepancy and correct the algorithm. In this example, only after
the selection of byte B7, the letter "з" should be highlighted on the right side.
Well, when selecting D0, nothing on the right should be highlighted. UNLESS, of course, you add these "voids"
between the characters to the rendering. Like in this example: https://i.ibb.co/nMqM44Wx/4.png

That was the first problem. And the second one is closely related to it. Now we take the lowercase letter "ж".
In our example, it is located very close, and therefore this problem is all the more striking.
UTF-8 bytes are: DO B6.
Image: https://i.ibb.co/W4Kt2SZ5/2026-02-26-110102.png
by analogy with all the previous drawn letters we expect that one character will be drawn for this pair - and that's the letter "ж"
and that's it. BUT in fact it turns out that BOTH bytes of the same character suddenly get their glyphs displaying on a screen!
And both of these mappings are in no way the desired letter "ж". I have reflected this situation in the picture above.
I hope this bug also will be fixed

[ghisler(Author)]

Sorry, I'm not understanding what I need to change. Do I select too much or too little?

[AntonyD]

From the point of view of the initial description of the problem from the first post, you are now highlighting everything correctly.

BUT there are special moments of single selection that have their own nuances. And I "painted" them. I described it in great detail.
Can you try to perform all the actions exactly as described above? The pictures also show these selections.
That is you have something to compare your selections with mine, reflected in the pictures.

[white]

That was the first problem. And the second one is closely related to it. Now we take the lowercase letter "ж".
In our example, it is located very close, and therefore this problem is all the more striking.
UTF-8 bytes are: DO B6.
Image: https://i.ibb.co/W4Kt2SZ5/2026-02-26-110102.png
by analogy with all the previous drawn letters we expect that one character will be drawn for this pair - and that's the letter "ж"
and that's it. BUT in fact it turns out that BOTH bytes of the same character suddenly get their glyphs displaying on a screen!
And both of these mappings are in no way the desired letter "ж". I have reflected this situation in the picture above.
I hope this bug also will be fixed

Not confirmed. Did you test with TC 11.56 by accident?

[AntonyD]

Did you use file exif_ru.lng from the first post? Did you turn on 65001 encoding for the font rendering?
If yes - you could not get different picture, imho. BUT! even if it was so - pls, post here your screenshots
made with the same selections as like mine were created.

[white]

Did you use file exif_ru.lng from the first post? Did you turn on 65001 encoding for the font rendering?

Yes.

If yes - you could not get different picture, imho. BUT! even if it was so - pls, post here your screenshots made with the same selections as like mine were created.

Screenshot

It seems you're using a different font though? You have dots representing the null characters.

[AntonyD]

Image: https://i.ibb.co/JRJ0BW8D/2026-02-26-180112.png
AS we can see - I am using the default settings as for Lister in overall so and for fonts particularly.
So which one is yours?
IF I understand correctly (and I've been asking Ghisler about this feature for a long time, MAKE the default font settings
fully displayed. With names), then my default font is Consolas.
IF I change the fonts, then I will see a different font, but I will NEVER get the same view as yours - without strange characters.

P.S.
And yes - I took the screenshot when I double-checked the fonts available to me.
But again, changing them has no effect on those special weird characters. They're always there.

[white]

AS we can see - I am using the default settings as for Lister in overall so and for fonts particularly.
So which one is yours?

Same settings and same font. I'm using Windows 11. You too?

[AntonyD]

10 + 11 = both.

There are no such characters when I use the same font, but in a specialized HEX-editor for example.
I.e. the font itself has no effect on the presence/absence of these "bad"-glyphs on the screen.

[ghisler(Author)]

OK, let me explain what was wrong in TC 11.56, and how I changed it in 11.57:
Lister does not draw an inverted rectangle on text. Instead, it first draws the not selected text, then changes the font foreground and background colors to the inverse, and draws the selected text.

11.56: This causes problems when the user has selected only a part of a character: When told to draw just the first or second byte of a character, Windows draws squares with question marks, or sometimes totally unrelated characters.

11.57: To fix this, TC now takes the ENTIRE character when the FIRST byte has been selected, and leaves out the character when the first byte hasn't been selected. This way we always get correct characters.

I'm also not getting your problem with the Cyrillic letter "ж". Here it looks like this:
https://www.ghisler.com/images/utf8-selection.png
This is with the default "Consolas" font on Windows 11.

[AntonyD]

It seems that you have explained the whole algorithm of HOW the rendering of a multibyte character works. And it seems to be understandable.
Of course, I don't really want to put up with this given that I see so many editors where the selection is done exactly as I described - the first
byte == selection of emptiness, the second byte is the character itself. BUT EVEN if we still agree that it currently works the way you say it does,
your second answer to the second problem described does not fit in any way In this answer!
Because in our example, a multi-byte character is PHYSICALLY divided into two bytes for rendering! That is, according to your algorithm,
YOU are REQUIRED to render each byte as a separate entity. And that's exactly what it looks like in my picture, and it logically matches
your algorithm. But how you made it draw everything in one character - that is the question!

I'm also clarifying that I get a rendering like mine - IN ANY font! that is, choosing a specific font DOES NOT CHANGE the fact that
for a multi-byte character that is physically split into two bytes on different lines, these gibberish characters are drawn.

To give you an idea of the peculiarity that my rendering variant is more correct than yours (although in mine incorrect extra characters is rendering):
it is clarification for the moment that in a pair of two bytes of this encoding - it is the second one that is responsible for the fact that there is an encoded character. And if the second one byte is on the other line - then the character corresponding to this pair of bytes must be on the second
line, i.e. your version of although it doesn't display the wrong extra characters on the screen - but it draws the actual location of the letter "ж"
on the wrong line!!!! This letter must begin the next line! So you have everything beautifully drawn - but completely wrong!

Image: https://i.ibb.co/Fk6K9731/utf8-selection.png
That is how it must looks like!