-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cross rendering in presence of surrogate pairs #56
Comments
Yes, ICU hide from me string structure. But when I working with whitespace and cross I using simple work with string Lines 631 to 633 in d557d88
how to reproduce this picture ? if enabled fullwidth-aware rendering , and using windows terminal 1.8.1521.0 I have many visual artifacts on rendering without cross ![]() after enable cross I have many visual artifacts , but not like you I can make the cross very long, but I cannot verify. --edit-- |
We're limited by the technology of our time, but one day it will work.
Nope, it's already enabled. Without it the the cross isn't really functional at all :) |
I thought we were waiting for a fix in terminal. Or turn it on https://github.com/FarGroup/FarManager/blob/956e9deb51627996b6cf7e115ecd7a0914b505af/far/interf.cpp#L790-L794 ? |
The latest conhost/wt can render these things more or less acceptably (as can be seen on the screenshot), and there is now a workaround in Far anyway (as the absence of the aforementioned comment in the current master implies), so no extra steps are needed. |
we need Interface.VirtualTerminalRendering = true. |
Ah yes, in non-VT mode we can't do much. |
I did a hack - doubled the length of the cross by default. I didn't find any other options, for example, to determine the size of the symbol when displayed. |
That should do, thanks. Far checks all the sizes and draws only what is needed anyway.
Determining the size of the symbol is a hard problem. |
Some codepoints in Unicode are represented by two
wchar_t
s, but logically occupy only one screen cell. Example.It looks like Colorer processes them correctly internally (thanks to ICU?), but there's at least one issue with rendering:
EditorColor.StartPos
andEditorColor.EndPos
are physical string indices, not screen coordinates. It works fine with the text, because Far is able to project physical indices into screen coordinates itself. However, these fields are also used for the cross, which is a visual element. TheEndPos
of the horisontal cross line is reported as if allwchar_t
s occupy exactly one cell, e.g. 120 if the editor width is 120, which doesn't look right if that's not the case:Coincidentally, this is not an issue for neither fullwidth
wchar_t
s (e.g. Katakana on the screenshot), because in that case the visual position is greater than the real and beyond the edge of the screen, nor for fullwidth surrogates (e.g. ideographs on the screenshot), because their fullwidthness compensates the collapse of theirwchar_t
s.The easiest way to fix this is probably reporting the right end of the cross as some ridiculously high number.
A better one, especially if there are other "visual" elements possible, would probably be introducing a new flag in
EDITORCOLORFLAGS
to let Far know that a particular EditorColor contains visual coordinates instead of real.The text was updated successfully, but these errors were encountered: