[raebened]

…(#21020, #5140)

Link to issue number:

Fixes #21020
Fixes #5140

Summary of the issue:

In Adobe Acrobat, when a header or cell in the last column of a tagged PDF table spans several rows (RowSpan), the next cell to reach that column is given a column number one too high. NVDA cannot navigate to that cell with table navigation commands and reports "edge of table".

A typical case is a header row where a column header with ColSpan is followed by a column header with RowSpan 2 in the last column. The first cell in the last column of the first body row is then numbered as column 7 of a 6-column table.

Cause: in nvdaHelper/vbufBackends/adobeAcrobat/adobeAcrobat.cpp, row spans were stored in TableInfo::columnRowSpans as a count of rows still to cover. That count was only decremented in handleColsSpannedByPrevRows, which runs when a later cell in a row walks past the spanned column. When no cell in a row lay to the right of the spanned column, the count was never decremented for that row, so it carried over into the next row and pushed a cell one column to the right.

Thanks to @ibromurph for the analysis posted on #21020, which reaches the same conclusion.

Description of user facing changes:

In Adobe Acrobat, cells beneath a row-spanning header or cell in the last column of a table are reported in the correct column and can be reached with table navigation commands.

Description of developer facing changes:

None.

Description of development approach:

TableInfo::columnRowSpans (column → rows still to cover) is replaced by TableInfo::columnLastSpannedRow (column → last row number covered by a span from a previous row). handleColsSpannedByPrevRows now skips a column only while the current row is within that range, so a span expires when its rows end, whether or not a later cell walks past it.

table-columncount is now taken from the highest column number used by any cell (TableInfo::maxColumnNumber) rather than from the column where the last row ends.

Testing strategy:

Manual testing with NVDA built from source with this change, in Adobe Acrobat (version 2026.002.22031) on Windows 11:

• The sample PDF attached to Adobe Acrobat: table navigation can’t reach last-column cell in first Body row of tagged PDF table #21020: Ctrl+Alt+Right Arrow across the first body row now reaches the last cell, and Ctrl+Alt+Down Arrow from the last column header moves to it.
• A client report table with the same header structure (row-spanning headers on either side of a column-spanning header, including the last column): all cells in the first body row are now reachable, which they were not before.
• [ADD: results for the second sample attached to Adobe Acrobat: table navigation can’t reach last-column cell in first Body row of tagged PDF table #21020]
• [ADD: a table that already worked before (no spans, or a row span in a middle column) still reads correctly]
• [ADD: the column count NVDA announces on entering the table is 6 columns

The span logic was also checked outside NVDA against the tables in #21020 a row span in the last column of a body row, and a row span in a middle column.

I'm not a developer. I used Claude (Anthropic's AI assistant) to find the cause and write this change. I built NVDA from source and did the testing above myself.

Known issues with pull request:

No automated tests are included; I'm not aware of existing tests for the Adobe Acrobat virtual buffer backend.

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

[seanbudd]

We would appreciate a secondary tester here