Commit Graph
3 Commits
Author SHA1 Message Date
John MacFarlane 3caf2b1e3a Revert "Docx reader and writer: support row heads."
This reverts commit cbe67b9602.

Word sets `w:firstColumn="1"` by default for tables.  You have to find
the Table Design tab and explicitly uncheck "First Column" to make this
go away.  In most cases, I don't think writers intend to designate
the first column as a row head, so this commit is going to produce
unexpected results.  In addition, because of the table normalization
done by pandoc-type's `tableWith`, any table containing a colspanned
cell in the left-hand column will get broken if the first column is
designated a row head.  For these reasons it seems best to revert this
change, which was made in response to #9495.

Closes #10627.
2025-02-19 10:02:50 -08:00
John MacFarlane cbe67b9602 Docx reader and writer: support row heads.
Reader: When `w:tblLook` has `w:firstColumn` set (or an equivalent bit
mask), we set row heads = 1 in the AST.

Writer: set `w:firstColumn` in `w:tblLook` when there are row
heads. (Word only allows one, so this is triggered by any number
of row heads > 0.)

Closes #9495.
2025-01-10 22:50:17 -08:00
Emily Bourke 56b211120c Docx reader: Support new table features.
* Column spans
* Row spans
  - The spec says that if the `val` attribute is ommitted, its value
    should be assumed to be `continue`, and that its values are
    restricted to {`restart`, `continue`}. If the value has any other
    value, I think it seems reasonable to default it to `continue`. It
    might cause problems if the spec is extended in the future by adding
    a third possible value, in which case this would probably give
    incorrect behaviour, and wouldn't error.
* Allow multiple header rows
* Include table description in simple caption
  - The table description element is like alt text for a table (along
    with the table caption element). It seems like we should include
    this somewhere, but I’m not 100% sure how – I’m pairing it with the
    simple caption for the moment. (Should it maybe go in the block
    caption instead?)
* Detect table captions
  - Check for caption paragraph style /and/ either the simple or
    complex table field. This means the caption detection fails for
    captions which don’t contain a field, as in an example doc I added
    as a test. However, I think it’s better to be too conservative: a
    missed table caption will still show up as a paragraph next to the
    table, whereas if I incorrectly classify something else as a table
    caption it could cause havoc by pairing it up with a table it’s
    not at all related to, or dropping it entirely.
* Update tests and add new ones

Partially fixes: #6316
2021-05-28 20:15:23 +02:00