-
Notifications
You must be signed in to change notification settings - Fork 173
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
Move HiStrCellsCount etc implementation to backend side #2378
Comments
So far, here are the ideas:
In theory, this approach should provide perfect rendering in any terminal capable of at least splitting into grapheme clusters in the same way we do, which of course requires up-to-date data from unicode.org, but at least it doesn’t depend on the font being used. |
Here is a sample script that uses just terminal interaction without any unicode libs to segmentation.py
|
NB! Far3 uses just the same logic: FarGroup/FarManager@272cee2 Search for |
This was actually invented here: https://github.com/magiblot/tvision/blob/master/source/platform/winwidth.cpp This link was posted to the FAR forum a long time ago. They ignored it then, but now they finally did it. Source: https://t.me/FarManager/15298 |
Some reasonable remarks:
|
iTerm2 has ESC sequence to specify Unicode version for characters with detection: |
All these functions rely on theoretically predicted visual sizes of grapheme clusters. However, our predictions do not account for the fact that adjacent grapheme clusters may display differently. In Unicode, there is no concept of character width outside of the string context in which it appears. Therefore, our approach cannot work perfectly even in theory. Additionally, the specific font affects the width, and in the case of a terminal, we don’t even have a rough idea of what the font is.
Instead, I propose a different approach. In the wx backend, we can ask wx itself for the pixel width needed to render a string, and then divide it by the pixel width of a cell, obtaining the minimum number of cells required to display the string.
In the tty backend, we can output the string outside the terminal window's space (above it, for instance), and by measuring the cursor's position after output, determine the number of screen cells occupied from the terminal's perspective. Performance can be significantly improved here by excluding this operation for strings that contain only characters guaranteed to have a width of 1 in all terminals and rendering libraries, such as Latin-1 characters, box-drawing characters, or Cyrillic characters.
In both cases, it is possible to retain the ability to revert to the current algorithm if performance issues arise.
UPD: guaranteed 1-cell-sized chars for fast size calculation:
The text was updated successfully, but these errors were encountered: