Variation selectors are not correctly handled #45
Labels
Comments
|
Sorry I just went through the README. Is such kind of cases not supposed to be handled by this package? |
|
This is a new one to me, yes, if iTerm and libvte-based terminals support it, then so should wcwidth! Thank you |
|
@jquast Then I'm afraid this is not the only case... There are also for example, Emoji Modifier Sequences, Zero-Width Joiner (and etc?). Unicode is crazy lol...
|
|
Multi codepoint emoji's covered in #39, zero-width joiners are sort of in 2 different issues.. Yes, Unicode 6.0 was so much easier when this project started :) |
jquast
added a commit
that referenced
this issue
Oct 30, 2023
Major ----- Bugfix zero-with characters, closes #57, #47, #45, #39, #26, #25, #24, #22, #8, wow ! This is mostly achieved by replacing `ZERO_WIDTH_CF` with dynamic parsing by Category codes in bin/update-tables.py and putting those in the zero-wide tables. Tests ----- - `verify-table-integrity.py` exercises a "bug" of duplicated tables that has no effect, because wcswidth() first checks for zero-width, and that is preferred in cases of conflict. This PR also resolves that error of duplication. - new automatic tests for balinese, kr jamo, zero-width emoji, devanagari, tamil, kannada. - added pytest-benchmark plugin, example use: # baseline tox -epy312 -- --verbose --benchmark-save=original # compare tox -epy312 -- --verbose --benchmark-compare=.benchmarks/Linux-CPython-3.12-64bit/0001_original.json
|
I have verified that this example in particular is fixed by #91 in today's release, thank you |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Variation selectors (U+FE0E, U+FE0F) can change column widths of some preceding characters. For example, U+270F (✏) is a single-column glyph by itself, but with a succeeding U+FE0F it occupies 2 columns as shown in the snapshot below.
The text was updated successfully, but these errors were encountered: