The current method to build a grid table is simple, hacky, and not very efficient. A better method would be to use a zipper, and building the grid diagonally from top left to bottom right.

Can you explain the problem that is being solved with this GridTable module? Isn't the current pandoc-types representation of a Table pretty much isomorphic to HTML table syntax? Shouldn't it be trivial to render it to HTML by just walking the tree? I am obviously missing something!

I see; I guess I was thinking, wrongly, that the alignments could be specified in the colgroup at the top.

I thought the same and am still confused as to why the align attribute on col elements is deprecated (and not even supported on Firefox).

I suppose it might be nice to have the table builder also infer what the individual cell alignments are, since it already has to go through the whole table and lay it out to fix cell dimensions and padding. That would have the nice side effect of making the cell alignment behaviour consistent across formats that support it.

The issue there, I think, is that some of the writers (LaTeX in particular) might want to know if the cell's alignment is consistent with the column alignments so that they don't output unnecessary cell alignment overrides. So the Alignment part of a Cell would need to be something like (Alignment, NeedsOverride) for that to work.

Though toLegacyTable (and so all the writers) already normalize their input Tables, so constructing an intermediate table with explicit alignment information would not be too different.

Shouldn't it be trivial to render it to HTML by just walking the tree?

I was hoping that as well.... so should we change the AST again, or...?

Just as a general comment on the request, the GridTable that's constructed doesn't really need to include the coordinates of the cell itself, at least not for the HTML writer, from what I understand of it. You only really need to add to the original Cell its inferred alignment, or maybe the [Alignment] list of the columns that the cell spans, and whether or not the cell is in the stub (the row head in a TableBody), though that might be better accomplished by creating a GridBodyRow that separates the stub cells in the row from the rest. That should be all that's necessary, and that data can be extracted from the table using the method that placeRowSection uses to lay out a table row on a grid for normalization.

A similar choice, but stylistically different, would be to stick a few helper functions somewhere that look something like

renderTableHead
  :: Monad m
  => ([Alignment] -> Cell -> m a) -- ^ render a cell given alignments of spanned columns
  -> (Int -> Attr -> [a] -> m b) -- ^ render a row given the row number and rendered cells
  -> (Attr -> [b] -> m c) -- ^ render the entire head
  -> [ColSpec] -> TableHead -> m c

the idea being that the function also takes care of the table layout work like the construction of the GridTable does. The corresponding renderTableBody function would need to be more complex, since table bodies have more components to handle.

All of this information can be recorded directly in the Table type, and can be pretty easily produced using a modified table builder. I think the reason why it was decided not to do so originally is that the extra cached data in the table can become incoherent or ill-formed, making the Table type even looser than it is already. Separating out the stub cells in each TableBody row means that the column width of the stub might vary within a single TableBody, for instance. But maybe that kind of redundancy and possibility for incoherence is better for ease of use?

Otherwise, if you'd like, I can write a GridTable and related constructor myself for that data, since I'm probably the most familiar with how the method in toLegacyTable and the normalizeTable functions works.

Otherwise, if you'd like, I can write a GridTable and related constructor myself for that data, since I'm probably the most familiar with how the method in toLegacyTable and the normalizeTable functions works.

That'd be great! I've written a less naïve toGridTable function in the meantime, but I'd much prefer a central function build with your expertise.

I wrote an alternate Writer.Tables in #6655.

I rebased to the current master, but now the new "planets" test table is missing a column. I suspect that there be an issue with the table annotator. @despresc, can you help?

Found the problem, misunderstanding on my part.

I think this is ready to be merged now.

I assume there are still some new table features in #6312 that are not yet addressed by this PR?

Still missing:

• intermediate headers
• footers
• attributes on all elements for which the information is available

I'll add a note to the issue.