Implements better character measurement. - #428
Merged
Merged
Conversation
This is an alterantive to the proposal in #418 which was a follow up to #409 Rather than special casing the keyboards that way, this improves the existing UITextInput handling and it improves the chinese, japanese and vietnamese output - but still fails with Korean. I could not figure out why iOS refuses to let me participate in the composition of text, even if the system seems to do just fine on its own (like native UITextFields). In particular this problem as documented by Nicolas: > Korean input: ㅇ followed by ㅜ produces 우 (as expected), but ㅇ ㅜ ㅇ produces 우ㅇ instead of 웅. So for Korean, I add a dreaded special case.
…aracters properly. And I discovered ucs-detect [1] along with a spec for how terminal emulators should measure unicode [2]. This patch implements that behavior. Unicode width now comes from UCD properties + EastAsianWidth W/F ranges and valid emoji‑variation sequences, and printing/combining now respects width ‑1/0 and only widens on valid VS16 (witha spacer cell) while dropping invalid zero‑widths. We had a discussion last week on GitHub about some of these problems, and my band-aid worked for a couple of things, but was by no means comphrenesive. [1] https://ucs-detect.readthedocs.io/intro.html [2] https://wcwidth.readthedocs.io/en/latest/specs.html The improvements are in: https://gist.github.com/migueldeicaza/a81dc7fd5a31f10cd24b2ba60b28a083 See the bug for before/after screenshots. This #427
min-median-max
pushed a commit
to min-median-max/SwiftTerm
that referenced
this pull request
Jan 18, 2026
For a while, we had a bit of a hodgepodge of attempts to measuring characters properly. And I discovered ucs-detect [1] along with a spec for how terminal emulators should measure unicode [2]. This patch implements that behavior. Unicode width now comes from UCD properties + EastAsianWidth W/F ranges and valid emoji‑variation sequences, and printing/combining now respects width ‑1/0 and only widens on valid VS16 (witha spacer cell) while dropping invalid zero‑widths. We had a discussion last week on GitHub about some of these problems, and my band-aid worked for a couple of things, but was by no means comphrenesive. [1] https://ucs-detect.readthedocs.io/intro.html [2] https://wcwidth.readthedocs.io/en/latest/specs.html The improvements are in: https://gist.github.com/migueldeicaza/a81dc7fd5a31f10cd24b2ba60b28a083 See the bug for before/after screenshots. This fixes migueldeicaza#427
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For a while, we had a bit of a hodgepodge of attempts to measuring characters
properly. And I discovered ucs-detect [1] along with a spec for how terminal
emulators should measure unicode [2].
This patch implements that behavior.
Unicode width now comes from UCD properties + EastAsianWidth W/F ranges and
valid emoji‑variation sequences, and printing/combining now respects width ‑1/0
and only widens on valid VS16 (witha spacer cell) while dropping invalid
zero‑widths. We had a discussion last week on GitHub about some of these
problems, and my band-aid worked for a couple of things, but was by no means
comphrenesive.
[1] https://ucs-detect.readthedocs.io/intro.html
[2] https://wcwidth.readthedocs.io/en/latest/specs.html
The improvements are in:
https://gist.github.com/migueldeicaza/a81dc7fd5a31f10cd24b2ba60b28a083
See the bug for before/after screenshots.
This #427