Created attachment 187178 [details] Example file from Word 2013 Attached example document contains a table with several rows where the row height is defined as "At least" 1.5 cm (numbers 34 - 36) and 0.6 cm (numbers 37-42). The rest is set as "Exactly" x cm. When imported in Writer the row height of those with "At least" value is a bit smaller than originally, compounding as much to have the last row of the table on the same page instead of breaking to the second page like in Word. This happens in DOCX/DOC/RTF formats as well. 1. Open attached document -> the row numbered 67 is at the bottom of the first page instead of at the top of the second. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 440c23ee678442fc64aa9fcca13b137738e10a04 CPU threads: 14; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: threaded and all the way back to 3.5
Created attachment 187179 [details] The example file saved as DOC
Created attachment 187180 [details] The example file saved as RTF
Created attachment 187181 [details] The DOCX example file in Word 2016 and Writer
Created attachment 187182 [details] The DOC example file in Word 2016 and Writer
Created attachment 187183 [details] The RTF example file in Word 2016 and Writer
Created attachment 187184 [details] The docx file saved as PDF with Word and Writer, compared in DiffPDF The DiffPDF tool shows that there is a compounding difference between row heights until the row 42, then the distance between the row borders is not growing anymore.
Created attachment 187185 [details] The example docx with row heights changed to exact values If I change the At least values to "Exactly" then the layout matches.
Created attachment 187186 [details] The modified example file in Word and Writer - layout matches I had to grow the last rows height by 0.2 cm before this, but with Exact row heights the layout matches.
Confirmed. Also confirmed the correct rendering in office.com. Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 41d96a72fc0e0a9fa35b6ac88a389473f8baedaf CPU threads: 8; OS: Linux 6.3; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 16 May 2023
*** Bug 156129 has been marked as a duplicate of this bug. ***
Created attachment 188236 [details] 155229_exact0.51cm.docx: 1 page document that becomes 2 pages with w:hRule="atLeast" Satya discovered that in Microsoft Office, "atLeast" heights are actually larger than "exact" heights - at least in their layout. Simply changing w:hRule="exact" to w:hRule="atLeast" will cause this 1-page document to become two pages in MSO. (I used MSO 2010 - the difference can easily be seen in the UI by simply selecting the table and changing the row heights from exact to at least.)
Created attachment 188237 [details] 155229_atLeast0.51cm.docx: 2 page document in MSO This is the identical document, with "exact" changed to "atLeast". The MSO documentation of course indicates that they OUGHT to be the same size. So this must be an MSO implementation detail. Thus it will be rather hard to guess what algorithm difference they use to determine the layout row height in these two cases. (Guessing wrong will lead to regressions in the other direction of having rows be too large, or round-tripping with a bigger TWIP result.)