Description: Table columns with text, the width depending on the text length can change, and the text will be split into two or more lines as it can be seen in LO 6.4 Steps to Reproduce: 1. Open attached file Actual Results: The column width should be the same as in Word, but it changes in LO 6.4 resulting in the text broken to two rows. Expected Results: Same column width Reproducible: Always User Profile Reset: No Additional Info: Bibisected using bibisect-win32-6.2 to: URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=fe847dda1751bc2c96ef646baa4f16bcc431c1e3 author: Justin Luth committer: Justin Luth summary: tdf#119760 writerfilter: cell border priority over tblBorder
Created attachment 153870 [details] The same sample file in Word and Writer 6.4
Created attachment 153871 [details] The sample file
Thank you for reporting the bug. I can reproduce the bug in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 But not in, Version: 6.3.0.0.alpha0+ Build ID: b6b28931435e44aca92b8c0e1659f701e3ed1a87 CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-01-30_06:57:04 Locale: en-US (en_US); UI-Language: en-US Calc: threaded
This bug report totally depends on the substituted font for "Book Antiqua". In Ubuntu 18.04, bibisect always loads on two lines - in 6.1 and 6.2. I don't see any difference in border spacing/width properties before/after either. The difference is that before the code was never evaluated since lcl_extractTableBorderProperty returns false, and thus LineWidth==0. Somehow (assuming a merge of the previous cell's RightBorder.LineWidth), this cell's aLeftBorder.LineWidth==18, even though LineStyle==NONE. However, I don't see how that affects anything except in theory the placement of the frame. I also see a minor difference in round-tripping. 6.1 improperly exported the table style as <w:left w:w="65" w:type="dxa"/>, while 6.2 exports the same as the original <w:left w:w="70" w:type="dxa"/>. I'm not sure how to proceed on this bug report since I can't reproduce it, see any property differences, or reproduce the export with w:w=65.
(In reply to Justin L from comment #4) > I don't see any difference in border spacing/width properties before/after. It looks like there was a bug back then - since changing the borders reverts back to 0.5cm each time you look at the properties - no matter what you set the value to. It ought to be 0.12cm for right and left. This seems to be a precision problem, since setting the same value that you see in the GUI it works correctly. The gui seems to treat it as 120, but the actual value is 123. Changing the actual value to 120 fixes it. It makes good sense to reduce the precision to the same as what the GUI would use, so that round-tripping a dialog box doesn't make any unexpected alterations.
Created attachment 154233 [details] 0001-tdf-127337-writerfilter-use-UI-matching-numbers-for-.patch: hacky fix that probably causes as many issues as it solves tdf#127337 writerfilter: use UI matching numbers for padding Using the UI rounds numbers (using denormalize and normalize). If the imported document doesn't exactly match these values, round-tripping a dialog box can inadvertently change some of the properties - so it is best to import UI-valid values. This solves the stated problem in bug 127337 since it rounds down and reduces the margin by the fraction of a cm needed. Of course, in other examples it could round up and cause a similar problem. So not a great overall solution, but neither is having a document change when just OKing a dialog...
Created attachment 155699 [details] Problem solved in LO6.4-master
*** This bug has been marked as a duplicate of bug 124367 ***