Created attachment 183203 [details] form261minimal.docx: best viewed with multipage view The problem is seen when comparing the two tables. The rows should be basically an identical heights. Now, the one on page 2 appears to have some bottom spacing. Broken by LO5.3 commit 1d1748d143ab4270a2ca1b5117852b1b1bb4c526 author Miklos Vajna on 2016-08-30 08:40:30 +0000 Related: tdf#44986 DOCX import: handle w:gridAfter by faking cells Steps to reproduce: -open form261minimal.docx. (It helps to view in multi-page view.) -the rows with XXX content should be identical heights with no spacing at the bottom border. It probably requires the format of the last column to be applied to the grid-after cells, although the default paragraph style and table styles don't seem to be relevant.
I confirm it with Version: 7.4.2.3 (x64) / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL in comparison with Word 2016. I have no idea what causes the different height of table rows: - there is no spacing below paragraph - row height is the same (fit to size) - no border padding at the bottom - no differences in style inspector
In lcl_CalcMinCellHeight, we get nLowHeight = Height of pLow->getFrameArea() of 240. That sounds very much like a default value. Yup - that is done in SwTextFrame::Format when GetWidth <= 0 - it also grows or shrinks the frameHeight to 240. But this is VERY generic code. Clearly this is not a true regression, but just a consequence.
Created attachment 184333 [details] form261minimalEXAGERATED.docx: without gridafter, just thin last column This shows it wasn't really a regression. It is the same file as the original, but with less rows (to make debugging easier) and thus is a round-trip from LO. Now it doesn't have a grid-after anymore (since fake cells took their place). It still runs up against the same code that forces a 12pt height. Interestingly, the comment about using 12pt font already existed before the code that sets the height to 240. commit 6c3ae34e32539f8493a940666dbe16b23a8ba7b0 Author: Frank Meies on Tue Nov 20 15:24:54 2001 +0000 Chg: Vertical Formatting - Growing frames
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cd7f8d895abae28533ec43ed43b2d90947e92b42 tdf#151704 sw: don't give random height to text frame It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
VERIFIED with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1c638b7ac46d8077994c8483e6becc4a33efd12b CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (de_DE); UI: en-GB Calc: CL threaded Justin, thank you for fixing it!