View Issue Details

IDProjectCategoryView StatusLast Update
0003564Far Manager_Commonpublic2017-12-01 15:04
Reporteremusic Assigned ToDrKnS  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionno change required 
Platformx86OSWindowsOS Version10
Product Version3.0 
Summary0003564: Under Win10, corrupt viewer/editor dialogs in UTF-16 modes with non-text files
DescriptionUnder Win 10.0.15063 x64 (maybe other builds too), if a non-text (for example, executable) file is open for viewing/editing and UTF-16 encoding (1200/1201) is set, viewer/editor dialogs are displayed corrupt. In one-byte code pages, dialogs are displayed normally.

100% reproducible in x86 5000/5100 releases and 5105 last night build.

Under Win7 SP1 x64, all dialogs are shown normally in all encoding modes.
Steps To ReproduceOpen an executable file in the viewer/editor.

Switch to UTF-16 (1200 or 1201) encoding.

Open any dialog (Help, Search, Plugin commands).
Tagsdialog, file, utf-16, win10
Build0

Activities

emusic

2017-12-01 12:41

reporter  

Edit-F7.png (12,290 bytes)   
Edit-F7.png (12,290 bytes)   
Edit-F11.png (14,379 bytes)   
Edit-F11.png (14,379 bytes)   
View-F7.png (13,321 bytes)   
View-F7.png (13,321 bytes)   
View-F11.png (12,838 bytes)   
View-F11.png (12,838 bytes)   

DrKnS

2017-12-01 12:49

administrator   bugnote:0015875

> Under Win7 SP1 x64, all dialogs are shown normally in all encoding modes

So... What makes you think it's a Far issue?

emusic

2017-12-01 13:29

reporter   bugnote:0015876

Last edited: 2017-12-01 13:30

Under Win10, text files in UTF-16 encodings and non-text files in single-byte encodings don't cause viewer/editor dialogs to be corrupt.

Do you think it is Win10 issue? If so, is there a workaround?

DrKnS

2017-12-01 13:37

administrator   bugnote:0015877

> Do you thing it is Win10 issue?

Obviously.

> is there a workaround?

Try vector fonts instead of raster.

The best way, of course, is to report it to MS.
The bug reporting tool comes with the windows as far as I know.

emusic

2017-12-01 13:46

reporter   bugnote:0015878

Last edited: 2017-12-01 13:58

Hmmm... But how Windows detects that FAR viewer/editor switches between its internal encodings?

With vector fonts, FAR dialogs are shown properly.

DrKnS

2017-12-01 14:11

administrator   bugnote:0015879

Last edited: 2017-12-01 14:13

Are you serious? It does not "detect" anything, text drawing is simply broken.
When you switch to utf-16 your single byte symbols become some unicode symbols, most probably some Chinese characters.
Your raster font does not contain such characters, so '?' is used as a substitution (that's why you can find a lot of '?' on your screenshots).
However, those CJK characters are typically 2 times wider than regular 1-byte characters. Perhaps someone in MS tried to "improve" the drawing function to take that into account and went too far, so now you have those regular substitution characters ('?') with doubled width as well and 2D character canvas is completely messed up.

emusic

2017-12-01 14:34

reporter   bugnote:0015880

I was sure that all character translation is performed by FAR so console drawing geometry should not be affected.

Thanks for the explanation, will report it to MS.

Issue History

Date Modified Username Field Change
2017-12-01 12:41 emusic New Issue
2017-12-01 12:41 emusic File Added: Edit-F7.png
2017-12-01 12:41 emusic File Added: Edit-F11.png
2017-12-01 12:41 emusic File Added: View-F7.png
2017-12-01 12:41 emusic File Added: View-F11.png
2017-12-01 12:41 emusic Tag Attached: file
2017-12-01 12:41 emusic Tag Attached: dialog
2017-12-01 12:41 emusic Tag Attached: utf-16
2017-12-01 12:41 emusic Tag Attached: win10
2017-12-01 12:49 DrKnS Note Added: 0015875
2017-12-01 13:29 emusic Note Added: 0015876
2017-12-01 13:30 emusic Note Edited: 0015876
2017-12-01 13:37 DrKnS Note Added: 0015877
2017-12-01 13:46 emusic Note Added: 0015878
2017-12-01 13:58 emusic Note Edited: 0015878
2017-12-01 14:11 DrKnS Note Added: 0015879
2017-12-01 14:13 DrKnS Note Edited: 0015879
2017-12-01 14:34 emusic Note Added: 0015880
2017-12-01 15:04 DrKnS Assigned To => DrKnS
2017-12-01 15:04 DrKnS Status new => closed
2017-12-01 15:04 DrKnS Resolution open => no change required
2017-12-01 15:04 DrKnS Build => 0