[Bug] Right-aligned numbers in source after prettification break unbordered table rendering in VSC's previewer.

[RokeJulianLockhart]

Examples And Explanation

Overflow     | 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 | Base-10 Value
------------:|----:|---:|---:|---:|--:|--:|--:|--:|-------------:
Inapplicable |   0 |  0 |  0 |  1 | 0 | 1 | 0 | 0 |            20
0            |   0 |  0 |  1 |  0 | 1 | 0 | 0 | 0 [^2] |            40

This renders as expected:

When prettified, its numeric values are shited to the right:

    Overflow | 128 | 64 | 32 | 16 | 8 | 4 | 2 |      1 | Base-10 Value
------------:|----:|---:|---:|---:|--:|--:|--:|-------:|-------------:
Inapplicable |   0 |  0 |  0 |  1 | 0 | 1 | 0 |      0 |            20
           0 |   0 |  0 |  1 |  0 | 1 | 0 | 0 | 0 [^2] |            40

Considering that tables aren't part of CommonMark, I don't know whether this is valid. However, it breaks the rendering of the table:

I apologise for the reproduction examples being so non-minimal. I'll attempt to reduce them when I've time.

My Environment

1. The Extension

   Version: 3.7.0
   VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=darkriszty.markdown-table-prettify

2. VSC ¹

   Name         : code
   Version      : 1.103.2
   Release      : 1755709837.el8
   Architecture : x86_64
   Install Date : Mon 25 Aug 2025 19:31:22 BST
   Size         : 453507130
   Signature    : RSA/SHA256, Wed 20 Aug 2025 18:15:13 BST, Key ID eb3e94adbe1229cf
   Source RPM   : code-1.103.2-1755709837.el8.src.rpm
   Build Date   : Wed 20 Aug 2025 18:10:40 BST
   Build Host   : c967556ec000000
   Packager     : Visual Studio Code Team <vscode-linux@microsoft.com>

Footnotes

1. rpm-software-management/rpm/discussions/3912 ↩

[RokeJulianLockhart]

#85 (comment)

This appears to be easily remediable by adding a border to the left and right:

|     Overflow | 128 | 64 | 32 | 16 | 8 | 4 | 2 |      1 | Base-10 Value |
|-------------:|----:|---:|---:|---:|--:|--:|--:|-------:|--------------:|
| Inapplicable |   0 |  0 |  0 |  1 | 0 | 1 | 0 |      0 |            20 |
|            0 |   0 |  0 |  1 |  0 | 1 | 0 | 0 | 0 [^2] |            40 |

[darkriszty]

Thanks for reporting this. I had a closer look and it seems the issue is caused by how unbordered tables handle alignments. Specifically, the first column shouldn't have leading inconsistent whitespaces, so the current behavior becomes problematic when there's no border and the first column is center or right aligned. This misalignment introduces inconsistent indentation and breaks rendering in some previewers like VSC.

To address this, I see a few possible approaches:

1. Adjust the padding logic so that the first column in unbordered tables always uses left alignment padding, regardless if it was center or right aligned.
2. Force borders on both sides of the table, which would resolve the issue but might frustrate users who prefer this extension because it supports tables without borders.
3. Introduce a config option to toggle between the above behaviors (and possibly a legacy mode with the current behavior), though this adds lots of extra complexity and might be overkill for most users.

Since preserving user intent over opinionated formatting (allow tables without borders) is a key philosophy of this project, I'm leaning toward the first option. I've already started working on a fix along these lines.

Happy to hear your suggestions.

[RokeJulianLockhart]

Adjust the padding logic so that the first column in unbordered tables always uses left alignment padding, regardless if it was center or right aligned.

@darkriszty, I agree with this. There's no point in adhering to the right-align override if it violates superordinate Markdown rules. The alternative – surrounding the table with borders – is so obvious of a solution that there's no need to override user intent.