Created attachment 198681 [details] ooo47393-2.doc: simple English text with Times New Roman font I'm seeing many DOC files where the spacing is no longer correct. Steps to reproduce: 1.) open ooo47393-2.doc Page 2 should start with "Mom! Mom!". Also seen with ooo393057-1, forum-mso-en-3196, and many more. But this patch has improved tdf85430-1.
Created attachment 198682 [details] ooo47393-2.doc_import-compare-0.png: RED=25.2 master, BLUE=25.2 oldest, grayscale=MSO2019 Prior to 25.2, the overlay was essentially identical to MSO. Now a lot of red is showing - and in the end an extra page is used. Found by Collabora's mso-test.
bibisected to 25.2 commit 2155684c819dcdc52968c59276046fb0cad83561 Author: Jonathan Clark on Thu Sep 19 22:05:08 2024 -0600 tdf#129808 sw: Use ext leading for text grid spacing on DOC import
Created attachment 198683 [details] 164803_more_examples.zip: a few additional examples I found
Document layout is affected by the MS_WORD_COMP_GRID_METRICS compatibility flag, even though it doesn't have a grid.
Created attachment 198720 [details] fdo64755-1.doc_import-compare-0.png: RED=25.2 master, BLUE=25.2 oldest, grayscale=Word2019 FFC252FFCSW_Chart_Paragraph0010.doc (aka fdo64755-1.doc, attachment 79515 [details] from bug 64755) might be an interesting example related to this bug. It changed with commit 2b030ded43f440a898733290af087d4aeed53368 Author: Jonathan Clark on Fri Sep 20 00:50:21 2024 -0600 tdf#85435 sw: No longer clear AddExtLeading for doc files with grid
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/43fc662520e5488cbeadd6eb60a24374a837dca4 tdf#164803 sw: Fix SwTextSizeInfo applying grid metrics without grid It will be available in 25.8.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.
This change fixes the ooo47393, forum-mso-en-3106, and ooo39439-1 cases. The ooo39057-1 case is due to an unrelated DOC import bug. When we import this file in LO, the first lines are flagged snap-to-grid. Microsoft Word treats them as though they aren't. You can verify this in Word by selecting the word "License" and adjusting the font size up and down. Note that the line doesn't skip to a different grid row. Now select the word "Please" from the third line and repeat the process. The line skips to different grid rows as the size increases. Strangely, the Word UI shows the paragraph style as snap-to-grid. However, if you convert to DOCX and look at the XML, snap-to-grid is indeed disabled.
Confirmed that this also fixes forum-fr-13961.doc, tdf31410-3.doc, abi7500-1.doc, and ooo42420-1.doc Confirmed that tdf85430-1 is still fixed from before.
Jonathan Clark committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/57614c6d6c2b95cfac83c22e4ed4a55d439b5cf4 tdf#164803 sw: Fix SwTextSizeInfo applying grid metrics without grid It will be available in 25.2.1. 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.
Created attachment 198750 [details] novell490734-1.doc: here is an interesting one that your patch did not fix I'm guessing this is a case where MS acts inconsistently - or else it has exposed an existing bug. There are HUGE spacing differences here.
(In reply to Justin L from comment #10) > novell490734-1.doc: here is an interesting one that your patch did not fix If I save as DOCX format (using Word 2010), then in Word it immediately jumps in size to match how LO displays it, simply by the act of saving in non-compatible-DOCX format. Based on my testing, it is related to the 14pt font size. The grid is set to 44 lines per page/15.6 pt, which the 14pt font apparently doesn't fit, so those lines take up two grid spaces. If I change the font to 13.5pt, then those lines fit. Or if I change the font to Courier (leaving 14pt size), then it fits. I can retain the .doc layout in the .docx by adding <w:compat> <w:noLeading/> /!-- Don't add leading (extra space) between rows of text --> </w:compat> That makes font size 14 become the cut-off to fit inside the 44 grid (since 14.5 again takes up two grid lines). So, when LO is deciding whether the line fits inside the grid, it probably needs to take ADD_EXT_LEADING into account.
(In reply to Jonathan Clark from comment #7) > The ooo39057-1 case. Importing in LO, flags the first lines snap-to-grid. Yup - they should... > Microsoft Word treats them as though they aren't. Agreed. The difference is the line spacing of "atLeast 0". Changing this to single line spacing, or specifying a non-zero atLeast causes Word to once again snap-to-grid for that paragraph. > if you convert to DOCX and look at the XML, snap-to-grid is indeed disabled. That I did not see. There were no <w:snapToGrid w:val="0"/> entries at all when I used Word 2010 to saveAs DOCX.
Created attachment 198763 [details] 164803_novell490734_noLeading.doc: 1 page because no leading, so 14pt fits in grid I don't see any evidence that the compatibility flag for ADD_EXT_LEADING should be ignored. If I remove that compat flag from this document, then the layout changes severely - taking up two pages. (In reply to Justin L from comment #11) > it probably needs to take ADD_EXT_LEADING into account. You can tell I'm not familiar with the grid. The entire point of your patch was to ignore ADD_EXT_LEADING. So now this has led full circle.
Created attachment 198764 [details] 164803_novell490734_withLeading.doc: Identical document, only with compat flag removed As noted earlier, I can reproduce the same thing in DOCX. It looks to me like your original premise is probably wrong, so probably the best thing to do is revert everything and start over again in master.
(In reply to Justin L from comment #12) > > Microsoft Word treats them as though they aren't. > Agreed. The difference is the line spacing of "atLeast 0". Created bug 164871 for this ^^^.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e5a7140c32a243782e21172a1ff9998720a063c3 tdf#164803 sw: Revert use ext leading for grid spacing on DOC import It will be available in 25.8.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.
(In reply to Justin L from comment #14) > It looks to me like your original premise is probably wrong, so probably the > best thing to do is revert everything and start over again in master. Agreed. I've reverted these changes. (In reply to Justin L from comment #15) > (In reply to Justin L from comment #12) > > > Microsoft Word treats them as though they aren't. > > Agreed. The difference is the line spacing of "atLeast 0". > Created bug 164871 for this ^^^. Thanks!
Jonathan Clark committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/55bacd19edc16d1e4c7109f0fcf16faf758620d9 tdf#164803 sw: Revert use ext leading for grid spacing on DOC import It will be available in 25.2.1. 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.