If I use Windows old-style cmd.exe to load Vifm, and use default color scheme and default Chinese font,it bahaves well, like this:
However, if I change another Chinese font, it appears strange squares, like this:
If I change color scheme, it appears spaces between the characters and messes the view, like this:
When I run Vifm in other shell programs of Windows, like Cmder, or run it in GVim, the view is also messed because of the spaces, like this:
I also use Vifm on Linux and it bahaves well, so it seems only happening on Windows. I like Vifm very much and want to use it on Windows with beautiful fonts and colorschemes. Could you help me to fix it or give me some advice how to do with it?
White background of inactive pane was just reported as a bug. I was wondering why does it look like that on your screenshots... In order to fix it, remove the line with OtherWin from colors/Default.vifm inside configuration directory (you can just do :e $VIFM/colors/Default.vifm inside Vifm).
I don't think vifm's behaviour can depend on a font of a terminal.
With color schemes it's somewhat different and might be a bug.
The thing is that terminal graphics library used by vifm on Windows doesn't have support for CJK languages and I had to add it manually. This includes these spaces, without them every second character gets lost (space moves cursor position). Not sure how, but looks like color makes that space visible.
I'll need to check this. Thanks for reporting this.
Thank you for your reply！
I think the display problem might not relate to the color scheme. It seems that while Vifm using default color scheme, cmd.exe uses its old mode, and while Vifm using other colorful color schemes, cmd.exe uses its new mode, which supports 256 true colors. So I guess that the graphics library gets wrong in the new-style terminal environment, which all support 256 or even more colors.
For me the issue doesn't depend on color scheme, but on font. And since it's a terminal property I'm inclined to blame it on the terminal. It's possible that I don't know something and therefore doing something wrong, but I don't think I had any success with documentation on my previous attempts to make CJK work.
I tried disabling my modification that adds space and at least on Windows 7 it didn't fix this offset in ConEmu, but moved characters and made a gap right after file names. Now I remember that this is how I noticed the issue of half of the characters missing, not sure it ever worked in ConEmu at all, I could be happy fixing it for cmd.exe in my tests.
I'll make some more tries on Windows 10, in case things became better there, and maybe try looking for example code that prints CJK successfully. If all that fails, then I won't be able to help, I just don't know why it is this way. Although, I have a feeling that it should actually work, cmd.exe can't be that broken with regards to CJK languages.
One more thing: depending on the font I also get some weirdness with Cyrillic symbols on Windows 10 ("абв", etc.) which never take more than one character position, yet they get messed up too. What the hell...
I did some more tests.
Behaviour on Windows 10 is the same.
Old vs. new console shouldn't matter because you switch between them in settings, it doesn't happen automatically.
Bugs with Cyrillic characters aren't result of my modifications, it's an issue with the terminal and fonts.
This code from Microsoft validates my approach of printing CJK. Just like they do, I output it in first cell and the one after it contains zero.
Given all this I don't know what else to do about it. I'll be happy to fix it, if anyone has any idea what might be causing it.