Created attachment 198725 [details] forum-mso-de-12204.doc_import-compare-0.png: RED=25.2 master, BLUE=25.2 oldest, grayscale=Word 2019 Not enough space was provided to accommodate the Windings symbol at 14pt in this 10pt paragraph. This is noticeable when comparing to MS Word's output. (This sounds like bug 163956, but the patch for that hasn't resolved the issue.) The extra space was lost with 25.2 commit f806fc136b3410ec9a1e09320d100c78b33c867b Author: Oliver Specht on Thu Jun 13 14:49:16 2024 +0200 tdf#137335 calculate paragraph height in RTF/DOCX Steps to reproduce 1.) Open mso-de-12204.doc Notice that the three line paragraph containing the ENVELOPE icon is identically spaced? The first line should have about 50% more space below it to accommodate the height of the enlarged field content, which is specified in DOCX as <w:r> <w:rPr> <w:sz w:val="28"/> </w:rPr> <w:sym w:font="Wingdings" w:char="002A"/> </w:r> Found by Collabora's mso-test
Created attachment 198726 [details] forum-mso-de-12204.doc: the file to test
Created attachment 198739 [details] forum-mso-de-12204.doc_import-compare-0.png: focused image - removed whitespace
Created attachment 198744 [details] forum-mso-de-83374.doc: also impacted by the identified commit
Created attachment 198745 [details] forum-mso-de-83374_word2010.png: screenshot of what should be in LO missing "open space"
Created attachment 198746 [details] forum-mso-de-83374.doc_import-compare-0.png: red/blue/grayscale overlay image
One problem seems to be in lines that consist of only tab spaces (which completely disappear now), caused by + bTmpDummy &= !pPos->InTabGrp() It breaks: -forum-mso-de-34519.doc (First three lines - should be tabs+CR, then 4pt CR, then tabs, spaces, field+CR) -forum-mso-de-83374.doc (pictured in comment 5) -forum-mso-en4-79154.doc (should have two empty CR directly above table(1)) -ooo104638-1.doc (first para should be tab+CR) The problem described in comment 0 was triggered by removing - .... && !rInf.GetLineStart()
(In reply to Justin L from comment #6) > The problem described in comment 0 was triggered by removing > - .... && !rInf.GetLineStart() That is perhaps fixed by mistake in LO 7.2, so don't flag that as a regression. commit 89e7341025b607491c90efdb74708e63d875c1e5 Author: Justin Luth on Thu May 27 14:32:54 2021 +0200 tdf#142404 sw compat layout: ignore blank size only on one-liners Similarly, the bTmpDummy looks like it might be a layout failure that is newly triggered. These are all examples where wrapping is occurring. I've seen comments stating that a Dummy line MUST have the same height and ascent.
(In reply to Justin L from comment #7) > That is perhaps fixed by mistake in LO 7.2 Definitely fixed by mistake. LO's sizing didn't come from the 14pt macrofield-button, but from a nearby 14pt preserved space.