Description: Exist *.ODT file from OpenOffice 4.1x (it is unimportant). In this file exist table (see page 1 in 7.ABCD.12345-47-13-01-OO.pdf). If this file is opened in LibreOffice table formatting is wrong (crashed) and I can't restore it: when I change table with, tables right+left spaces is moved without assistance. Checked on 6.4.4.2 (installed) and 7.2.4 (portable) Steps to Reproduce: 1. Open file 7.ABCD.12345-47-13-01-OO.odt in a LibreOffice Writer 2. See table at the left side of the page 1 3. Compare with OpenOffice Writer (or see PDF: 7.ABCD.12345-47-13-01-OO.pdf) Actual Results: Table at the left side have a wrong format. Original values: alignment: manual table with: 12 mm table space left: 0 mm table space right: 0 mm column 1 with: 4,9 mm column 2 with: 7,1 mm When file open in LibreOffice: alignment: manual table with: 6.4 mm table space left: 0.5 mm table space right: 0.5 mm column 1 with: 2,6 mm column 2 with: 3,8 mm I can change any field, but any other fields changing without assistance (like an autoformat mode). Expected Results: table size must be the same Reproducible: Always User Profile Reset: No Additional Info: PORTABLE! Version: 7.2.4.1 (x86) / LibreOffice Community Build ID: 27d75539669ac387bb498e35313b970b7fe9c4f9 CPU threads: 6; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win Locale: en-US (ru_RU); UI: en-US Calc: threaded
Created attachment 177490 [details] ODT-file with table at the left side of the page 1
Created attachment 177491 [details] Right table view
Created attachment 177492 [details] Wrong table view in LibreOffice
Sorry - instead one PDF in attachment two PNG files
No repro 5.2+, repro 5.3+ and 7.4+. Like I saw it earlier, but I couldn't find. Minor because it can be corrected and saved in new LO and it opens OK. Lin 53: commit 17d8234546ccc7b6cd69f3288c5ee086d48b7b1c Date: Thu Nov 3 22:33:58 2016 +0100 source 5d9d0f3c979732ade57b9c4c4960dd030ffdc9f9 prev 2a818a0aafac218ca09bb079d7f2cf0879385e4a author Justin Luth <justin_luth@sil.org> 2016-11-02 there is a function for that: CalcLineSpace(xx, bEvenIfNoLine) That commit is mentioned in multiple reports. https://bugs.documentfoundation.org/show_bug.cgi?id=107946#c4 says: "So, it is not really a current bug. Unfortunately, in various ways LibreOffice previously allowed you to create improperly designed documents that specified a spacing that it didn't display. (Usually LO automatically sets the value to zero when a border is removed.)" But https://bugs.documentfoundation.org/show_bug.cgi?id=117449#c18 says: "I'm afraid that this needs to be chalked up to old bugs in LO, and you will just need to manually fix the documents that need the adjustment to look right." So I guess this can be marked as duplicate. Although I don't get how this issue around padding spoiled frame size, that needs to be adjusted now. *** This bug has been marked as a duplicate of bug 107946 ***
Yes, this is a duplicate, and is tied to bug 41542. > Before 5.3, LO improperly (according to ODF specs) ignored that padding setting. So the key here is to notice that the squished table is inside of a frame. The frame specifies border padding (but not a border line). According to ODF spec, the padding should be honoured, even if the line is not active. However, OOo and LO5.2 ignored the padding in that case. So it was an implementation failure that was fixed (without a compatibility flag) and thus requires manual intervention to correct these kinds of problems.