TODO:

• Workaround for diagonal line being above cell borders (z-order argument in place typst/typst#2603) Done by manually drawing the cell's stroke e4c3b9b
• Detect from context if we are in a table or grid => is it possible?
• If no inset is specified, take the global inset from the container, like table.cell and grid.cell do => is it possible?
• Improve width / height heuristic for different text sizes colliding with the diagonal line

Thanks!

I don't think we should fully scrap the old code, or, at least, what it was meant to do. I think we should write the code in a way that is generic to any box or block, including the stroke information. Then, the cell variants would only invoke the generic code with some adjustments. If we keep the inset handling, they could then simply specify an inset of 0pt when calling the generic version.

In addition, I'd like to keep the old sep parameters if possible as they are also used in the LaTeX package.

Finally, we should rename the parameters and variables to use kebab-case, e.g. text-width. This package is very old (dates back to Typst 0.1.0 I think?) so this convention wasn't that widespread at the time. :p (But feel free to leave this job for me.)

Workaround for diagonal line being above cell borders

Not possible to move it under, you will have to reduce the line's size to start at (stroke width / 2, stroke width / 2) and end at (cell width - stroke width / 2, cell width - stroke width / 2). Might need some additional finetuning based on the stroke width of the line itself.

I saw your workaround but it doesn't sound like a good idea in general for grids/tables. First, this ignores global stroke options. In addition, table layout has fairly complex code to merge cell lines together, as well as handle lines of colspans, rowspans, cells spanning multiple pages and the presence of gutter which can't easily be simulated in our side. Requiring the user to specify a stroke width or assume a default of 1pt and use that to pad the line is a more reliable approach.

We can of course do that outside a table or grid if the user asks us to draw a stroke. Inside a grid or table, I suppose we can keep the feature there optionally as a last resort.

Detect from context if we are in a table or grid => is it possible?

No.

If no inset is specified, take the global inset from the container, like table.cell and grid.cell do => is it possible?

Outside of grids and tables you mean, e.g. in a block? If so, no.

Table cell and grid cell are laid out by the grid itself, so they are aware of global cell properties at that time.

Improve width / height heuristic for different text sizes colliding with the diagonal line

I wonder what is different from the old code, or did this problem exist before? If it's the latter, I wouldn't mind doing it in a separate PR.