Supporting CJK characters in MD060

[HowieHz]

Hello, I would like to ask how to fix the MD060 issue.

I use Prettier to format Markdown files, which produced the following table:

| 路径匹配       | 匹配区域                   |
| -------------- | -------------------------- |
| `/archives/**` | `article .content`         |
| `/moments`     | `article .content .medium` |
| `/moments/**`  | `article .content .medium` |
| `/photos`      | `article .content`         |
| `/photos/**`   | `article .content`         |

It looks most like the "aligned" style, so I set:

  // MD060/table-column-style : Table column style : https://github.com/DavidAnson/markdownlint/blob/v0.39.0/doc/md060.md
  "MD060": {
    // Table column style
    "style": "aligned",
  },

I also used markdownlint-cli to run the lint check, but it reports the following error::

  MD060/table-column-style Table column style [Table pipe does not align with heading for style "aligned"]

This is the PR from the update; the actions in it might help analyze the issue: HowieHz/halo-theme-higan-hz#291

I created a demo to reproduce this issue. You can access it here: stackblitz

I suspect this rule has poor support for CJK characters.

Thank you for reading this far. I wish you a pleasant life.
(My English is not good, so I used a translator.)

[yuluo-yx]

hi @HowieHz, you can refer: vllm-project/semantic-router#700

[DavidAnson]

Below is an example of your table with no warnings. It's not that the rule does not support extended characters but instead that the width they are rendered at can be inconsistent. This scenario is described a little more with emoji examples here: https://github.com/DavidAnson/markdownlint/blob/main/doc/md060.md

https://dlaa.me/markdownlint/#%25m%23%20Issue%201869%0A%0A%7C%20%E8%B7%AF%E5%BE%84%E5%8C%B9%E9%85%8D%20%20%20%20%20%20%20%20%20%20%20%7C%20%E5%8C%B9%E9%85%8D%E5%8C%BA%E5%9F%9F%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%7C%0A%7C%20--------------%20%7C%20--------------------------%20%7C%0A%7C%20%60%2Farchives%2F**%60%20%7C%20%60article%20.content%60%20%20%20%20%20%20%20%20%20%7C%0A%7C%20%60%2Fmoments%60%20%20%20%20%20%7C%20%60article%20.content%20.medium%60%20%7C%0A%7C%20%60%2Fmoments%2F**%60%20%20%7C%20%60article%20.content%20.medium%60%20%7C%0A%7C%20%60%2Fphotos%60%20%20%20%20%20%20%7C%20%60article%20.content%60%20%20%20%20%20%20%20%20%20%7C%0A%7C%20%60%2Fphotos%2F**%60%20%20%20%7C%20%60article%20.content%60%20%20%20%20%20%20%20%20%20%7C%0A%0A%3C!--%20markdownlint-configure-file%20%7B%0A%20%20%22MD060%22%3A%20%7B%0A%20%20%20%20%22style%22%3A%20%22aligned%22%0A%20%20%7D%0A%7D%20--%3E%0A

[HowieHz]

Below is an example of your table with no warnings. It's not that the rule does not support extended characters but instead that the width they are rendered at can be inconsistent. This scenario is described a little more with emoji examples here: main/doc/md060.md下面是你的表格示例，没有警告。并不是规则不支持扩展字符，而是它们渲染时的宽度可能不一致。这里用表情符号做了更详细的描述：main/doc/md060.md

dlaa.me/markdownlint#%m%23 Issue 1869 | 路径匹配 | 匹配区域 | | -------------- | -------------------------- | | %2Farchives%2F** | article .content | | %2Fmoments | article .content .medium | | %2Fmoments%2F** | article .content .medium | | %2Fphotos | article .content | | %2Fphotos%2F** | article .content | dlaa.me/markdownlint#%m%23 1869 年第 1 期 |路径匹配 |匹配区域 | |-------------- |-------------------------- | |'%2Farchives%2F**' |“条目.content” | |'%2Fmoments' |'条目 .content .medium' |'%2Fmoments%2F**' |'条目 .content .medium' |'%2Fphotos' |“条目.content” | |'%2Fphotos%2F**' |“条目 .content” |

Thank you for your reply @DavidAnson. I think Prettier's formatting results might be more "aligned". What I mean is, considering that CJK (Chinese, Japanese, Korean) characters typically occupy two character widths in monospaced fonts, perhaps we could provide an option to calculate CJK characters as two units wide; or provide a configuration that allows specifying character sets to be calculated with specified widths.

For example, like the implementation in this PR: prettier/prettier#3003

[DavidAnson]

On my iPhone in the GitHub web UI editing a Markdown file, the right-most pipe characters would align perfectly if the check mark emoji each rendered with the width of two standard characters (3x2 = 5+1). However, that pipe character renders too far to the right which means these emoji occupy something like 2.1 normal character widths!

Assuming an exact width of 2.0 does not work for the first character I tried, so this does not seem like a guaranteed improvement to me. Furthermore, I do not see a good way to account for fractional widths even if we could tell exactly how wide each character would be for each font/program/OS/etc..

| Response | Emoji |
| -------- | ----- |
| Yes      | ✅✅✅|

[Mister-Hope]

Yes, that's why I also suggest providing some options that may:

1. adjust CJK, emoji and even other characters widths individually
2. support ignoring table that contain special characters (tables writing with en still get "aligned" while table with other characters are ignored) This is better than disabling the rule entirely, since markdownlint itself and its CLIs does not support ESLint overrides that allow us to tweak rules for some files with globs.

Currently, when handling multilingual docs and working with tools like prettier, I did not see any chance to get it enabled.

[HowieHz]

@DavidAnson Thank you for the response. I understand your concern about emoji rendering inconsistencies, but I'd like to suggest we treat CJK characters separately from emoji as a starting point.

CJK characters have much more reliable width behavior than emoji:

CJK characters (Chinese/Japanese/Korean) in monospaced fonts have a well-established convention of occupying exactly 2 character widths. This is standardized through:

• Unicode Standard Annex (East Asian Width)
• The widely-adopted wcwidth implementation
• Consistent behavior across modern terminals, editors, and monospaced fonts

Unlike emoji (which as you demonstrated can render at fractional widths like 2.1), CJK characters have predictable width behavior that tools like Prettier, VS Code, and most terminal emulators handle consistently.

There are already mature implementation solutions:

Prettier handles similar issues using the is-fullwidth-code-point library to determine character width. For example, in prettier/prettier#3003, they implemented accurate width calculation for fullwidth characters using this library.

For more precise Unicode EastAsianWidth specification implementation, there's also the is-full-width library, which provides a complete implementation conforming to the official Unicode EastAsianWidth specification v11.0.

Proposed approach:

"MD060": {
  "style": "aligned",
  "use_east_asian_width": true  // Uses fullwidth calculation for CJK
}

This would solve the immediate alignment issues with CJK content (which is very common in Asian markets) without trying to solve the more complex emoji rendering problem at the same time. Emoji support could be considered separately later if needed.

What do you think about this approach?

[DavidAnson]

If I understand correctly, you're saying CJK characters are consistently rendered at exactly the width of 2 "normal" characters. The original example from above uses the below four Chinese (?) characters, so I'd expect the rendering of the following table on GitHub under macOS with all defaults to line up perfectly. But that's not what I see - the result is off by 2 full "normal" character widths. (I can provide an image if you don't see the same thing. But I also checked the behavior in VS Code and it's off by about 1.5 characters.) Therefore, I do not think this 2-character width convention is consistent or universal. Maybe if I changed my OS language the rendering would change, but I don't love the ambiguity and inconsistency of that.

| 路径匹配 |
| -------- |
| 12345678 |

The suggestion above to ignore all tables with "special" characters seems like something that could reasonably be done. It would probably mean that tables with any non-Latin characters like emoji, CJK, etc. would never be subject to MD060. Maybe that's the least bad option, but I'd love to come up with something better if we can.

[HowieHz]

路径匹配
12345678

@DavidAnson Thank you for the response. I mean that, with a monospaced font, a fullwidth character should occupy the width of two halfwidth characters. In practice, however, there may be differences due to various typographic optimizations (fonts are not perfectly monospaced). How to implement this is up to you — having grown up in a CJK environment, I may treat this as common sense, so it might be hard to explain the matter clearly at first.

EDIT: Screenshot from China's largest Q&A community.
https://www.zhihu.com/question/334669192

[DavidAnson]

Thanks. I'll experiment with this tonight.

[gibfahn]

For what it's worth I came across this because I updated markdownlint, and now the way prettier formats my markdown then triggers markdownlint. It would be great if these two tools did the same thing.

Example:

| Foo | Bar    |
| --- | ------ |
| A   | ✅⚠️❌ |

path/to/t.md:23:14 MD060/table-column-style Table column style [Table pipe does not align with heading for style "aligned"]

What it looks like in kitty terminal / Hasklug Nerd Font Mono:

Interesting that GitHub shows it as non-aligned...

[DavidAnson]

@gibfahn, what behavior are you saying prettier implements? Your sample suggests it may be treating emoji as two characters also? Can you give some examples of how prettier formats things so I can get a sense of what compatibility might look like?

[Mister-Hope]

Thanks for the research @gibfahn did.-

Again I want to express my opinion, a better default value should be provided for sure. But since there are CJK fonts that are not 2:1 exactly, also the emoji width may be different in different fonts, we might need to provide an option to tweak emoji and CJK characters width?

In most editors (like VS Code), you are able to customize editor fonts. For most Chinese developers, we are expected to choose an exact 2:1 font (which will greatly improve developing experience with CJK), while GitHub itself might be a little bit different, so people shall be able to manually choose the way they want to align the tables.