Fix Table column widths being truncated for the first and last columns

[yyccPhil]

Overview: What does this pull request change?

This fixes the first and last columns of a Table (and its subclasses MathTable, IntegerTable, and DecimalTable) being truncated when explicit col_widths are passed through arrange_in_grid_config. Grid lines and cell borders now follow each column's arranged slot instead of the bounding box of its contents, so the requested column widths are honored for every column.

Closes #3446

Motivation and Explanation: Why and how do your changes improve the library?

When col_widths makes a column's slot wider than its contents, arrange_in_grid centers the (narrower) content inside the slot. However, Table._add_vertical_lines() and Table.get_cell() anchored the outer grid lines and cell borders to the content extent (get_columns()[i].get_left()/get_right() ± half h_buff) rather than to the slot. The outer columns were therefore drawn narrower than requested, and because the anchor depended on the content width, the truncation was asymmetric (a column with narrow contents was clipped more).

Reproduction from the issue, rendered at width 10 with col_widths=[3] * 6:

• Before: per-column widths ≈ [1.00, 1.84, 1.85, 1.85, 1.85, 1.60] — first and last columns visibly clipped.
• After: [1.667] * 6 — all columns equal, col_widths honored.

Before / after

Before:

After:

The change adds a small helper, Table._get_column_x_edges(col_index), which returns the left/right x-coordinates of a column's arranged slot:

• When no width is set for a column, it returns the column's content edges — i.e. exactly the previous behavior — so default tables are unaffected. (I verified numerically that the vertical-line positions and get_cell() corners are unchanged to within 1e-9 for a default table.)
• When a fixed width is set, it returns the slot edges and respects col_alignments ("l", "c", "r").

_add_vertical_lines() (both outer and inner lines) and get_cell() now use this helper.

Links to added or changed documentation pages

No documentation pages are changed by this PR.

Further Information and Comments

• Added a regression test, test_table_col_widths_are_honored, in tests/module/mobject/test_table.py, modeled on the existing regression tests there. It fails on main and passes with this change.
• Scoping question for reviewers: when row/column labels are present they shift column indexing relative to col_widths, so the helper intentionally keeps the previous content-based behavior for labelled tables to avoid changing their output. I'm happy to extend the fix to labelled tables as well if you'd prefer — just let me know which you'd like.

This is my first contribution to Manim, so any feedback is very welcome!

Acceptance criteria

• Tests added for new/changed behavior (test_table_col_widths_are_honored)
• All tests passing (existing tests/module/mobject/test_table.py suite + the new test)
• Follows the project style guide (ruff check and ruff format --check pass)
• No breaking changes introduced (verified the default, no-col_widths path is byte-for-byte unchanged)
• Documentation updated (if applicable) — n/a, no documentation pages affected

Reviewer Checklist

• The PR title is descriptive enough for the changelog, and the PR is labeled correctly
• If applicable: newly added non-private functions and classes have a docstring including a short summary and a PARAMETERS section
• If applicable: newly added functions and classes are tested

[behackl]

Thanks for taking a look at this, much appreciated!

Please find two particular examples of Table usage below where the expected behaviour does not match the actual behaviour yet:

from manim import Table, Text

table = Table(
    [["a", "b"], ["c", "d"]],
    row_labels=[Text("r1"), Text("r2")],
    col_labels=[Text("c1"), Text("c2")],
    top_left_entry=Text(""),
    h_buff=0.1,
    include_outer_lines=True,
    arrange_in_grid_config={
        "col_widths": [2, 3, 3],  # row-label column, then two data columns
        "col_alignments": "ccc",
    },
)

xs = sorted(line.get_center()[0] for line in table.get_vertical_lines())
widths = [xs[i + 1] - xs[i] for i in range(len(xs) - 1)]
print(widths)

This should produce widths [2.1, 3.1, 3.1], but doesn't because labels are not handled correctly yet.

Second example:

from manim import LEFT, Table

table = Table(
    [["a"]],
    h_buff=0.1,
    include_outer_lines=True,
    arrange_in_grid_config={
        "col_widths": [3],
        "cell_alignment": LEFT,
    },
)

column = table.get_columns()[0]
actual_left = min(line.get_center()[0] for line in table.get_vertical_lines())
expected_left = column.get_left()[0] - table.h_buff / 2

print(actual_left, expected_left)

Text is not always centered in the cells, so it should not be treated as such; in particular the left grid line is shifted too much.

Could you please take a look, let me know whether or not you agree with the (in)correct behaviour for these two examples and see whether there is a nice and straightforward way to get this fixed?

Thanks again!

[yyccPhil]

Hi @behackl ! Thanks for the detailed examples, I've pushed a fix.

For the first example, I'd special-cased labelled tables to fall back to the old content-based behaviour, which was too conservative — col_widths actually lines up 1:1 with get_columns() even when labels are present (the label column is just column 0), so I removed that early return. Now it gives [2.1, 3.1, 3.1] in the first example.

For the second one, the helper I created only looked at col_alignments and otherwise assumed the content was centered. It now determines each column's horizontal alignment the same way arrange_in_grid does — an explicit col_alignments entry wins, otherwise it falls back to the horizontal component of cell_alignment — so left/right-aligned content is placed against the correct slot edge. The second example now matches column.get_left()[0] - h_buff / 2.

I also added regression tests for both cases.