Forum Feature requests

Provide a mechanism for column-spanning table captions

David J Prokopetz
Prince currently handles tables which span multiple columns well, with the exception of the table caption element.

As shown in the first attached example (multi-column-table.html), all features of the table's layout operated as expected in a multi-column context, but the caption occupies only the first column, resulting in an unbalanced distribution of rows.

A visual workaround is possible by floating the caption to the top of the column, as demonstrated in the second attached example (multi-column-table-floated-caption.html). However, when the output profile is set to PDF/UA-1, this workaround results in a different PDF document tree, with the caption element being inappropriately located. (Both attached PDFs have been generated using this output profile for your reference.)

As it stands, there doesn't seem to be any way to achieve balanced columns with a table which has a caption while also achieving correct semantic tagging in PDF/UA-1 output.
  1. multi-column-table-floated-caption.html1.7 kB
  2. multi-column-table-floated-caption.pdf30.4 kB
  3. multi-column-table.html1.7 kB
  4. multi-column-table.pdf30.4 kB

Edited by David J Prokopetz

David J Prokopetz
Upon consideration, I suppose an alternative approach would be to provide a mechanism for specifying that an element that's been floated to the top or bottom should retain its original, pre-floated tag type and position in the PDF/UA-1 document tree. That would also address this particular issue.
howcome
Hello David,

I'd say that the current Prince rendering is correct. That is, in a multi-column context, the table caption should only appear in the first column.

However, I also see that spanning columns can be visually appealing. Your proposed solution, in your second message, would address the semantic tagging issue for your use case, as well as many other use cases that will appear when millions of authors see the beauty of page floats.

David J Prokopetz
Oh, I didn't mean to suggest that the current behaviour is incorrect according to the spec – merely that there's an obvious use case for doing otherwise. That's why this is in the "Feature requests" forum, not the "Bug reports" form.

Edited by David J Prokopetz

howcome
A commendable feature request!