Description: Table cell has some text and that renders in two lines where as the original document has the text in one line. Steps to Reproduce: 1.Open the attached "Table_Cell_Multi_line_issue.docx" in both MS office and in the LO. 2.Check the difference between both. Actual Results: The tex renders in two lines. Expected Results: The text should render same as in the original document, i.e., in single line Reproducible: Always User Profile Reset: No Additional Info: Attachments: "Table_Cell_Multi_line_issue.docx" and "Multi_line_issue.png"
Created attachment 187868 [details] Table_Cell_Multi_line_issue
Created attachment 187869 [details] Multi_line_issue
Justin L
Justin, Could you please throw some light on this area to start with it ?
repro 24.2+. bibisect-releases indicates it started at 4.0.0.1 (not beta). Table border spacing (LO) / Cell Options (MSO) agree with 0.27cm each Table column width: LO 2.40cm, MSO 2.41cm (preferred). Changing LO's column width to 2.41 "fixes" the problem. Likely the value is kept as integer during conversion processing and loses precision - usual fix is to use double for as long as possible.
Justin,Vajna This particular line pSeparators[nBorder].Position = rtl::math::round(nRelPos + nLastRelPos); in DomainMapperTableManager::endOfRowAction() is modified multiple times in the past for various reasons. for example see below commit, in this commit added rounding of the value https://git.libreoffice.org/core/+/29cbbad64088354425c606f9eb6c267bdf7731dc%5E!/ later again removed this rounding of the value see this commit https://git.libreoffice.org/core/+/e502463fa9a601963aa9f5a8783eb1318de36c13%5E%21 now in the latest code we are doing rounding again.. For this particular issue, when I apply a ceil then the issue will be resolved like pSeparators[nBorder].Position = rtl::math::round((nRelPos + nLastRelPos), 0, rtl_math_RoundingMode_Up); or simply ceil(nRelPos + nLastRelPos) but I don't know applying ceil will cause any regressions, or Is this not the better place for this issue. Please provide some inputs to fix this issue.
(In reply to SATYA SRINIVAS K from comment #6) > but I don't know applying ceil will cause any regressions... I'm sure it will cause regressions for other documents. Since the for loop is already using a double, I'm not really sure what could safely be done here.
Probably the next step is to see if there are any other bugs affecting cell size. -Is it a floating table? No (LO OK). -Is it relative width? No - 15.89 cm preferred width. (LO OK) -Spacing left (.31cm) in LO, but not seen in MSO. Removing "fixes" bug. -assuming this was added due to border width - emulation about positioning? -perhaps it is irrelevant when position is centred instead of left/right?
Created attachment 188021 [details] screenshot of test DOCX in Office.com (Noting that the word "NOTICE" is split over two lines on Office.com as well.) Bibisecting with the linux-43all repository, I get to first bad commit 142a2a6ac236d6e9946bfbf51b6bfcc616958e98 which points to core commit: commit 540f090a68ae4375a36d0ee6dfbb4a82f28ac704 author Jan Holesovsky <kendy@suse.cz> Fri Jan 04 22:02:34 2013 +0100 committer Jan Holesovsky <kendy@suse.cz> Fri Jan 04 22:02:53 2013 +0100 Fix build on linux. I double-checked because I was surprised a change to the jpeg filter would be the culprit...
Noel and Mike discussed this in detail on IRC. I think the summary is that we believe this is a precision problem. The DOCX file has column widths in twips, the Writer UNO API (used by the DOCX import) works with relative sizes: the separators are declared on a 0..10000 scale. Writer core than converts this back to twips values internally. It is believed that the fix will be to add an extended way to transfer these column width from writerfilter/ to sw/, a way that allows working with twips values end-to-end.
Apologies for not getting the actual range of commits. The bibisect result with linux-43all is this range: https://git.libreoffice.org/core/+log/f6b4d0313dbaf1089254a1bfae9ccfbc3f413eb3..540f090a68ae4375a36d0ee6dfbb4a82f28ac704 Miklos, possibly 60ec497e0e91354a616978be531d15d3efa3f559 ?
Possible. But if so, then this really just worked by accident before. The discussion mentioned in comment 10 sounds like a promising direction to explore.
(In reply to Miklos Vajna from comment #12) > Possible. But if so, then this really just worked by accident before. The > discussion mentioned in comment 10 sounds like a promising direction to > explore. yes, it stopped working after this commit,but it was working accidently before. we have some margins that are started working after this commit and that is expected and earlier the margins were missed and text started rendering from the beginning so we couldn't see this problem.