Thicker table (v)line becomes longer and exceeds the table bounds/borders

[Andrew15-5]

Description

The code:

#table(columns: 2, [a], table.vline(stroke: 2pt), [b])

Outputs:

Which is true for different PDF viewers and for 1000 PPI PNG. This is clearly visible on PDF and PNG at a normal zoom, probably will be visible on a A4 paper as well. And it appears there is no solution to make the table line thicker without extending its ends outside of the table's borders. IMO, this is a serious limitation on table customization, even though tables only "recently" (end of last year?) got a major update. The issue can go as a feature request as well, but I chose to treat it as a bug.

Reproduction URL

No response

Operating system

Linux

Typst version

• [X] I am using the latest version of Typst

[PgBiel]

In principle this isn't a bug, lines normally expand on all sides, which is important to make corners merge together, otherwise the corners would be empty. With that said, there could be an additional option for stroke.cap controlling which sides to expand a line's thickness on, so that could be considered a feature request.

[Andrew15-5]

As a limited solution, you can increase the thickness by around 90% via gutter:

#table(columns: 2, column-gutter: 0.9pt, [a],  [b])

Which would give nice and crisp result:

If the gutter uses +100% of the line thickness, then you would see the gap between the cells, like this:

But there is a catch: normally changing table line thickness never spreads the cells between themselves, but in this case it does. So if you have some specific table/cell sizes, then you have to count in these gaps as well.

[Andrew15-5]

which is important to make corners merge together, otherwise the corners would be empty.

Right.

In principle this isn't a bug, lines normally expand on all sides

Yes, but you can literally say table.vline(stroke: (thickness: 2pt)) which, in the context of middle vertical table lines, means that you want to change only the thickness, i.e., expand the line horizontally. Instead, it expands it in all directions. So it all depends on what you/user thinks the stroke should do. In this situation, it clearly shouldn't expand in all directions. Therefore, I consider it's a bug, but it also doesn't matter.

[Enivex]

In principle this isn't a bug, lines normally expand on all sides, which is important to make corners merge together, otherwise the corners would be empty. With that said, there could be an additional option for stroke.cap controlling which sides to expand a line's thickness on, so that could be considered a feature request.

I mean, this is clearly not desired behavior, and I'd argue a bug. The line shouldn't expand past the extent of the horizontal stroke it intersects with.

[PgBiel]

I mean, this is clearly not desired behavior, and I'd argue a bug. The line shouldn't expand past the extent of the horizontal stroke it intersects with.

It's complicated, since they are just lines, so there is no hierarchy of strokes when things are being drawn. With your proposal, you'd get sample A instead of B.

[PgBiel]

Strokes have a few intrinsic problems as well, such as which lines to draw on top, horizontal or vertical lines. We chose the thickest lines to be drawn on top, which is what browsers do. But there are other things which are much harder to solve. We could try to think of an alternative way to handle strokes if we want to tackle this.

[Enivex]

I mean, this is clearly not desired behavior, and I'd argue a bug. The line shouldn't expand past the extent of the horizontal stroke it intersects with.

It's complicated, since they are just lines, so there is no hierarchy of strokes when things are being drawn. With your proposal, you'd get sample A instead of B.

I don't understand your logic. I'm not saying they shouldn't extend. I'm saying they should only extend by half the stroke width of the horizontal line, and not past it. That would give you B.

Currently it's extending too far.

[Andrew15-5]

I thought of a quick and dirty solution like wrapping the table in block(clip: true) if the extended line doesn't actually take space (like place()). I haven't tried this, but this is probably can be added to the Rust code as a temporary/permanent(?) fix. Or some version of it.

[PgBiel]

In principle, I'm ok with adding this as a feature as far as is possible. I'm just not sure if this should be the default behavior, especially because different behaviors make more sense for different situations, so I think we should at least be able to switch between both behaviors.

With that said, there are still design decisions to make:

• What if there is no horizontal line at the top in the initial example? Should the vertical line then not extend at all, or should it behave as it does today?
• What if the two cells around the vertical line have strokes with different thicknesses? Should it stop at the stroke with largest thickness?

[Enivex]

• What if there is no horizontal line at the top in the initial example? Should the vertical line then not extend at all, or should it behave as it does today?

No horizontal line would be the same as a stroke of width zero, so it shouldn't extend

• What if the two cells around the vertical line have strokes with different thicknesses? Should it stop at the stroke with largest thickness?

Yes, though I can imagine having three options. Either no extension, extend to the smallest, or extend to the largest. It would also make sense to have the ability to shorten lines instead. That would be 5 options total.