Word 2013: issue with table row of exact height

Hi rpr,

I commend you on a very well done and succinctly presented documentation of a problem. And I empathize because I am also suffering with table row length and alignment anomalies in Word 2010 and 2013.

Your analysis clearly demonstrates that Word is not considering the table cell border and margin setting as being part of the row height "exact" calculation. Most likely, only paragraph point height is included. Clearly a design flaw in my opinion.

BTW - I'm pretty sure compatibility with LibreOffice will not factor into any consideration for fixing this problem.

Sorry that I don't have a workaround solution for you.

Richard,

it's not actually a question of LibreOffice compatibility with Word but with the document format the data are saved to.

DOCX is part of Office Open XML format standardized as ISO/IEC 29500. The purpose of standardization is to achieve interoperability: if two applications implemented that standard correctly then documents interchanged between them would look the same.

But, things are not that simple because there are three different versions of OOXML (ECMA, Transitional and Strict) that are not compatible with each other -- see a lengthy explanation (or at least the management summary) at https://joinup.ec.europa.eu/elibrary/case/complex-singularity-versus-openness

I'd say it shows a typical Microsoft's approach to interoperability: make things too complicated for everyone else to implement except ourselves.

-- rpr.

Doug,

Your suggestion is appropriate for text paragraphs inside table cells but what about cells that contain other objects that can't be controlled by paragraph formatting? For example, you insert a picture that floats over text and you want to position it in relation to the cell margins -- see the following options available in Word 2013:

Having top/bottom margin set to 0 is not convenient in such a case (and by increasing the margins you increase the row height).

BTW, if you set both top and bottom cell margins to 0.1 cm the row height increases for 0.1 cm, not 0.2 cm, which one would expect. What's the logic behind this?

-- rpr.

There is a bug in Word which needs recognition and a fix.  Bottom cell margin (padding) dimensions are being added to exact cell height dimensions in error.  Top cell margins are NOT being added to exact cell height dimensions, which is appropriate and is the means by which we can tell this is an oversight.

If top, left, and right cell margins have no affect on the size of table cells, neither should the bottom cell margin.  Note in the image below Word shows the table as having .50" x .50" cells and as seen in the image, all cells  are clearly taller than wide. 

Hopefully someone at Microsoft will look into getting this fixed for us.  It would be deeply appreciated by all.

Many thanks,

Dave

I can confirm this is a bug in Word (2013 & 2016)!

The bottom cell margin is added to and increases the cell height! in preview, but doesn't display this increase in the cell height box. My cell height was specified as 74 mm and the bottom margin was 5 mm. So the cell height was actually 79 mm, and moved my bottom row to the next page. I'm using A4 paper with 297 mm height, so 74 × 4 = 296 mm, but 79 × 4 = 316 mm, which doesn't fit on one page

A workaroud until this is fixed is to reduce the fixed cell height by the amount specified in the bottom cell margin.

So if you want your cell to be 74 mm, and you want a cell margin of 5 mm, then set the bottom margin to 5 mm, and reduce the cell height by the amount you specified in the bottom margin (69 mm in this example).

I was making a label, and thought I was crazy. There are so many ways to mess up the sizes once you start working with tables (the page  margin, the paragraph space, paragraph indentation), so it took me an hour to figure out it was Word's fault!

Z

Hi Zoran,

You do not appear to be running the same version of Word as the original poster. Can you please confirm what specific version of Office (PC or Mac) that you are running and seeing this behavior?

Hi Richard,

I'm running O365BusinessRetail (v 16.0.4229.1029), but I've also tried v 15.0.4711.1003, and the same behaviour is present.

Regards,

Zoran

UPDATE 26/10: Same behavior on v 16.0.6001.1034