fix(remark-grid-tables): support fullwidth tables #312
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.
This PR adds fullwidth support for
remark-grid-tables
.Fullwidth forms are the string representation that consumes double width in render. So far
remark-grid-tables
assumpted that every letter being rendered in the same width on the screen, thus it failed to handle fullwidth letters. In other words, the implementation currently treats the length of a string and the width of a string are equal, which is not always the case in some writing systems (like East Asian countries).For instance, let's see the current behavior that requires:
which makes almost impossible to correctly format a table by hand because:
Hello
andこんにちは
are both 5 letters but consumes different widthDog
and🐶🦄👍
are both 3 letters but consumes double as wellIn order to solve this issue, this PR fixes calculation and string operarion to carefully distinguish display width with the support of
@nxmix/is-full-width
and makes the following expression possible:(Screenshots are attached because GitHub seems to render those letters incorrectly. Using Unicode terminals are fine though.)
Another issue that is solved is surrogate pairs. JavaScript internally processes strings in UTF-16 to make us deal with some messy operation. For example, DOG FACE (🐶) is U+1F436; these codepoints like the ones emoji use have some restriction over string operators:
length
:Array.from()
:Therefore, the utility functions are added for all the cases above:
Thanks for any efforts made to this package!