[Feature Request] make simple colspan in pipe_tables work

[terefang]

Describe your proposed improvement and the problem it solves.

the pipe table here

| Size       |Modifier | Health |Size Min|Size Max|Wgt Min|Wgt Max|Space|Reach (Tall)|Reach (Long) |Biped(\*)|Quad(\*)|
|:--------|:-----:|:-----:|:-----:|:-----:|:-----:|:-----:|:-----:|:-------:|:-------:|:-------:|:-------:|
| Minuscle   |  ±5D    |    1   |    –   |   3in  |   –   |  4dr  | < 5ft |  0ft  |  0ft  | ×1/16 | ×1/8 |
| Fine       |  ±4D    |    2   |   3in  |   6in  | 4dr   |  2oz  | < 5ft |  0ft  |  0ft  | ×1/8 | ×1/4 |
| Diminutive |  ±3D    |    4   |   6in  |   1ft  | 2oz   |  1lb  | < 5ft |  0ft  |  0ft  | ×1/4 | ×1/2 |
| Tiny       |  ±2D    |    6   |   1ft  |   2ft  | 1lb   |  8lb  | < 5ft |  0ft  |  0ft  | ×1/2 | ×3/4 |
| Small      |  ±1D    |    8   |   2ft  |   4ft  |  8lb  | 64lb  |  5ft  |  5ft  |  5ft  | ×3/4 | ×1 |
| Medium     |  ±0D    |   10   |   4ft  |   8ft  | 64lb  | 512lb |  5ft  |  5ft  |  5ft  | ×1 | ×2 |
| Large      |  ±1D    |   12   |   8ft  |  16ft  | 512lb | 4klb  | 5-10ft| 10ft  |  5ft  | ×2 | ×3 |
| Huge       |  ±2D    |   14   |  16ft  |  32ft  | 4klb  | 32klb | 10ft  | 15ft  | 10ft  | ×4 | ×6 |
| Gargantuan |  ±3D    |   16   |  32ft  |  64ft  | 32klb | 256klb| 20ft  | 20ft  | 15ft  | ×8 | ×12 |
| Colossal   |  ±4D    |   18   |  64ft  |  128ft | 256klb| 2Mlb  | 40ft  | \*  | \*  | ×16 | ×24 |
| Titanic    |  ±5D    |   20   |  128ft |    –   | 2Mlb  |   –   | > 40ft| \*  | \*  | ×32 | ×48 |
|*) Carrying Capacity multiplier.    ||||||||||||

will look like this:

the table is rendered with pandoc to typst source and then using typst to pdf:

$ pandoc --from markdown+pipe_tables+raw_attribute+fenced_divs+yaml_metadata_block --columns=10 --lua-filter=./template/pagebreak.lua --lua-filter=./template/tabledivs.lua --embed-resources --standalone --template=./template/template.typ  ./markdown/*.md -o ./out/index.typ

$ typst compile --root ./ --pdf-standard "a-2b" --ignore-system-fonts --font-path ./assets/fonts ./out/index.typ ./out/index.pdf

the pipe table is formatted according to https://github.com/vsch/flexmark-java/wiki/Tables-Extension.

Especially this rule:

... column spans can be specified by adding consecutive | at the end of the cell. Each pipe represents column span count || spans two columns, ||| three, etc.

When column span syntax is enabled, empty table cells must have at least one space. Otherwise they will be interpreted as column spans for the previous cell.

Edge cases: since the rule does only allow to "eat" cells from the right side for spanning the following two cases have undefined behavior.

||||||||||||| *) Carrying Capacity multiplier.    |
||||||| *) Carrying Capacity multiplier.    |||||||

or do you have a good idea ?

Describe alternatives you've considered.

1 - considered to switching to other tables styles, but pipe-tables are so easy to explain to non-tech people.

2 - massaging the table cells with a lua script, which did not work because the surrounding whitespace is eaten making "| |" and "||" indistinguishable.

[jgm]

For discussion see
https://talk.commonmark.org/t/tables-in-pure-markdown/81/145

[terefang]

ok i have read the discussion starting from you link.

i am now largely confused and dont know what to make out of it.

• on one side you expressed exactly the need for features i would also suggest
• on the other side you wrote this:

  Pipe tables look increasingly like line noise the more features are added, while grid tables look just like tables. But grid tables seem quite unpopular due to the need to align columns.

to summarize:

• there is "prior art" (ie support) for colspan in at least Flexmark, MultiMarkdown and Maruku
• you proposed rowspans using "^" markers.
• there is a proposal for per cell alignment using ":" (colon) markers.
• pipe-tables are more popular than grid-tables.

i would like to implement the feature in a lua-filter but for the reason stated above this is not possible without changes in the pandoc parser.

i am also not inclined to invent new syntax for supporting this in a lua-filter when there are multiple implementations already out in the field that do the same.

hence confused.

[jgm]

You're confused because I list both pros and cons? I think that it is probably worth implementing something like this feature in pipe tables, but I've wanted to think more about all the possibilities before locking in syntax. And...I have other things to do, as well.

For now...just use a grid table!

[terefang]

You're confused because I list both pros and cons? I think that it is probably worth implementing something like this feature in pipe tables, but I've wanted to think more about all the possibilities before locking in syntax. And...I have other things to do, as well.

sorry now i understand ... dont take this as persuasion to implement the feature asap, but as user-feedback to make you understand my point and possible to help you in your decision making.

ok, let me relist the proposed features:

1 - ||... — as a colspan indicator
2 - : — as custom align indicator for cells
3 - ^ — as rowspan indicator
4 - |{.class a1=v1 ...} — as attribute assignment to cell

maybe it gets easier to view this as a 20:80 problem, what is easy to implement and has a large acceptance target.

also to consider the usage by casual vs advanced users that will also use custom (lua-)filter to further massage output.

• feature (1) would have a large satisfactional value among casual users as there is "prior art" and "recognizable value"
• feature (4) would have a large satisfactional value among advanced users for building out filters.

in my case i would consider myself an advanced user, but then my use-cases are mostly implemented for casual users that use my templates and filters almost verbatim since they lack the in-depth knowledge ... so i care for both.

from an architectural point, you could argue that "pipe_tables" are good as they are now and that the expansion of features would warrant a "smart_pipe_tables" extension. that would also preserve existing user experience and expectations.