View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003564 | Far Manager | _Common | public | 2017-12-01 12:41 | 2017-12-01 15:04 |
Reporter | emusic | Assigned To | DrKnS | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Platform | x86 | OS | Windows | OS Version | 10 |
Product Version | 3.0 | ||||
Summary | 0003564: Under Win10, corrupt viewer/editor dialogs in UTF-16 modes with non-text files | ||||
Description | Under 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 Reproduce | Open an executable file in the viewer/editor. Switch to UTF-16 (1200 or 1201) encoding. Open any dialog (Help, Search, Plugin commands). | ||||
Tags | dialog, file, utf-16, win10 | ||||
Build | 0 | ||||
|
|
|
> Under Win7 SP1 x64, all dialogs are shown normally in all encoding modes So... What makes you think it's a Far issue? |
|
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? |
|
> 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. |
|
Hmmm... But how Windows detects that FAR viewer/editor switches between its internal encodings? With vector fonts, FAR dialogs are shown properly. |
|
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. |
|
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. |
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 |