FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

How to preserve spaces in GFM tables? · Issue #443 · commonmark/commonmark-java · GitHub

Repository navigation

How to preserve spaces in GFM tables? #443

Description

Hello,
in my project there are many table of the form

| A |B|
|---|-|
| 1 |2|

When I use the GFM table extension they are correctly parsed, but all spaces are removed and that make editing the table impossible afterwards. Is there a way to prevent this condensation of the existing spaces?

Activity

  1. robinst commented on Aug 1, 2026

    Collaborator

    You mean after rendering the table back to markdown using MarkdownRenderer?

    We're probably not preserving spaces there. The fix is going to be preserving that information on parsing and then taking it into account on rendering as well.

  2. peterdell commented on Aug 1, 2026

    Author

    You mean after rendering the table back to markdown using MarkdownRenderer?
    Yes.

    I think not putting the spaces is valid behavior for programmaticly generated MDs and if nobdy complained so for, it should probably a builder option.
    I also wanted to have automatic spacing and formatting of the "|---|---|" separator lines. Not sure if that is worth to be in the standard.
    I've implemented that in my modified copy here: https://github.com/atariwiki-org/wiki-tools/tree/main/src/org/commonmark/ext/gfm/tables
    It for now only looks into the width of the header text. Mid-term I want to check also the really used column-width in all rows (with a maximum of N chars).

  3. robinst commented on Aug 2, 2026

    Collaborator

    Right, so what we want is not to preserve the input spaces, but instead an option to render any table with visual alignment. Yeah, I think that makes sense!

    Mid-term I want to check also the really used column-width in all rows (with a maximum of N chars).

    Yes, so it will need an additional pass over all cells, but that's ok. We'll need to actually render all the cells to strings first, then visually align the resulting strings (bonus points for handling Unicode combining marks, zero-width joiners and full-width characters correctly). Do you want to raise a PR for that?

  4. robinst commented on Aug 10, 2026

    Collaborator

    bonus points for handling Unicode combining marks, zero-width joiners and full-width characters correctly

    Btw I looked into that, it's not easy to do without extra Unicode data (e.g. ICU4J). I recommend we:

    • By default count grapheme clusters (assuming one cluster = 1 column), using BreakIterator
    • Allow consumers to pass in a Function<String, Integer> for overriding width calculation (e.g. using ICU4J's EAST_ASIAN_WIDTH data).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL