latex tables: Fix rendering for grid filled merged vertical cells#14024
Merged
jfbu merged 2 commits intosphinx-doc:masterfrom Dec 21, 2025
Merged
Conversation
0e7c941 to
6df55e4
Compare
Contributor
|
Thank you for contribution and sorry for late. I will rebase on current master because at my locale I got a test failure which a priori is unrelated, so I need to investigate this in the proper context suitable for merging in time for 9.1.0. |
The table from issue sphinx-doc#9313: .. table:: :class: standard nocolorrows +--------------------+----------------+ | 2 rows and 2 cols | 1 row x 3 cols | | +----+-----+-----+ | | A | B | C | +---+----------------+----+-----+-----+ | 1 | 2 | 3 | 4 | 5 | +---+----------------+----+-----+-----+ has merged vertical cells that notably needs to draw a vertical line on the left and right-hand side of the cells in the 2x2 grid area. If you add a column to the left of this: .. table:: :class: standard nocolorrows +---+---+----------------+----------------+ | X | 2 rows and 2 cols | 1 row x 3 cols | | | +----+-----+-----+ | | | A | B | C | +---+---+----------------+----+-----+-----+ | Y | 1 | 2 | 3 | 4 | 5 | +---+---+----------------+----+-----+-----+ then the 2x2 area should *not* draw a column line to the left of the area. We can fix this by adjusting the \multicolumn invocation to adjust when it emits the colspec. Notably, this commit does *not* consider the other broken case where a person maybe just wants the table borders like: .. tabularcolumns:: |llllll| .. table:: :class: standard nocolorrows +---+---+----------------+----------------+ | | 2 rows and 2 cols | 1 row x 3 cols | | X | +----+-----+-----+ | | | A | B | C | +---+---+----------------+----+-----+-----+ | Y | 1 | 2 | 3 | 4 | 5 | +---+---+----------------+----+-----+-----+ That has an impact in this area of the code, but to correctly consider that one has to parse out the given colspec to determine which columns have borders between them. (This line of code has a bug for this case as the colspec being emitted should be conditional if the specific column actually has it enabled, but the supporting code only determines if a vertical line is enabled anywhere rather than which columns.)
6df55e4 to
c3e9a22
Compare
Contributor
Author
You're welcome, and no worries about it taking a while. Thanks for merging! |
AA-Turner
pushed a commit
to pradyunsg/sphinx
that referenced
this pull request
Dec 31, 2025
…hinx-doc#14024) Co-authored-by: Jean-François B. <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The table from issue #9313:
has merged vertical cells that notably needs to draw a vertical line on the left and right-hand side of the cells in the 2x2 grid area. If you add a column to the left of this:
then the 2x2 area should not draw a column line to the left of the area.
We can fix this by adjusting the \multicolumn invocation to adjust when it emits the colspec.
Notably, this commit does not consider the other broken case where a person maybe just wants the table borders like:
That has an impact in this area of the code, but to correctly consider that one has to parse out the given colspec to determine which columns have borders between them. (This line of code has a bug for this case as the colspec being emitted should be conditional if the specific column actually has it enabled, but the supporting code only determines if a vertical line is enabled anywhere rather than which columns.)
Here are the three tables mentioned prior to this fix:
And after the fix (which just fixes the second case):
Notably, the 3rd case (which is not a full grid fill) leaves extra vertical lines, and an extraneous "dot".