Column widths of table are set, document is then saved but on re-opening the document, the table's column widths are (very) wrong. Reproducible? Yes. Happens many times. Happened in previous versions? Yes.
Hello MrKing, Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
As noted ideally provide a test document that demonstrates the issue with Table columns. Please understand that the 5.1.6 build is EOL for the 5.1 branch (i.e. nothing will be changed). Best if you can install current 5.2.3 release and retest. If still an issue, please provide full Steps to Reproduce, including the format you are saving the document as (ODF or OOXML) and the test document.
Created attachment 128763 [details] Example of deformed column widths after saving and re-opening. I do not seem to be able to submit a LibreOffice odt document to show you so I have attached a pdf of the same document.
I have just done a clean install of LibreOffice_5.2.3.3_Linux_x86-64 and the same problem exists.
Created attachment 128766 [details] odt file showing example table Another attempt to save an odt file showing the problem.
I see the column width error. But when going to 'table properties' > 'line arrangement' and set the right most arrows in 'user defined', save and reload, the table width stays the same. If I insert a table myself, save and reload, the column border doesn't get removed. So how can we reproduce this one from scratch ?
Sorry, MM, I can't find the menu item to which you refer. On my version of Writer (Version: 5.2.3.3, Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf) the menu tree looks like this:- Table > Properties... Clicking on 'Properties...' opens a dialog entitled 'Table Format', which has the following tabs:- Table, Text flow, Columns, Borders and Background. There is no mention of 'line arrangement' in any of those tabs and therefore there is no facility to "set the right most arrows in 'user defined'". Right-clicking in the table and then clicking on 'Table properties...' produces the dialog box just described above. As stated before, this column distortion error only ever happens on a newly-created document that is saved for the first time, closed and then re-opened for the first time. Once the document has been saved two or more times, the table columns settings stay as they were saved.
Check with 5.1.6.2 and 5.2.3.2 under ubuntu 16.04 x64 and 5.1.6.2 under windows 7 x64. Line arrangement is in the borders tab. When you switch 'on' the right most arrows (set outer border and all inner lines), save and reload, these stay on. Also tried it with a new file, made a table, saved. But, all borders stay on.
MM, yes thanks, I found line arrangement where you said it was. The reason for my confusion is that my post did not refer to borders at all. My problem is with the column widths initially set by me being lost on first saving the file and then re-opening it (please see my original and subsequent posts). Losing borders is a trivial problem for me compared with having my carefully saved column widths wrecked and, in some cases, having the last column (and all the data in it) disappear completely.
For me not reproducible with LO 5.2.3.3 (Win 8.1).
no repro too under Win8.1 x64 using LibO 5.2.3.3 must be Linux specific
Created attachment 128959 [details] Step-by-step reproducibility instructions and screenshots
Created attachment 128960 [details] As above in pdf format The problem can be reproduced using Windows 10 Pro and LibreOffice 5.2.3.3 and reproduction instructions are shown in the attached document.
Created attachment 128964 [details] sample .fodt document table with 3 columns -- loses one on opening
Created attachment 128965 [details] same sample .odt archive document with 3 columns -- loses one on opening Confirming loss of display of third column on reopening document. The .fodt and .odt archive include the column in ODF as style-name Table1.C1 & Table1.C2--but they do not render to document canvas.
Confirmed on Windows 10 Pro 64-bit (1607) en-US with Version: 5.2.3.3 (x64) Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US); Calc: group and current master Version: 5.3.0.0.alpha1+ Build ID: 0f3861e65d8e652dcc31cf9a2f2b5c1a0a73b86d CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; Layout Engine: new; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-19_23:33:29 Locale: en-US (en_US); Calc: CL
This is a regression between 4.3.6.2 and 4.4.6.3 releases, needs to be bibisected. Here are STR 1. Open Writer 2. enter two rows of text, separated by tabs Column1 <tab> Column2 <tab> Column 3 <return> 25% width <tab> 35% width <tab> 40% width <return> 3. select that text 4. Table -> Convert -> Text to table 5. uncheck "equal width for all columns" if set 6. Table -> Select -> Table 7. Table -> Properties (Table Properties on older builds) 8. On Table Properties dialog -- note table width 6.93" (en-US Letter) 8a. Table tab: set Left radio button 8b. Columns tab: set width of columns 1.73", 2.42", 2.77" 9. save to ODF (.odt or .fodt) 10. while open the canvas shows all three columns 11. close 12. reopen -- 3rd column is missing, and 1st and 2nd column are stretched.
Regression as of Version: 4.4.4.3 Build ID: 2c39ebcf046445232b798108aa8a7e7d89552ea8 Locale: en_US
Occurs somewhere between the 4.4.2.2 release and the 4.4.4.3 release... https://cgit.freedesktop.org/libreoffice/core/log/?h=libreoffice-4-4&qt=range&q=c4c7d32d0d49397cad38d62472b0bc8acff48dd6..2c39ebcf046445232b798108aa8a7e7d89552ea8
Working on debian-stretch in the 50max bibisect repository, following the steps in comment 17, I see that the was introduced somewhere in the 8 commits ... commit s-h date -------- -------- ------------------- good 8d7a017c 853c2fc7 2015-01-23 13:04:25 bad a7d852ff ad50b9a8 2015-01-23 16:13:24 In detail, (lines rewrapped) ... terry@lynn-stretch:~/lo_hacking/bibisect/bibisect-50max$ git bisect skip There are only 'skip'ped commits left to test. The first bad commit could be any of: 5fd8a74fb9ca7ad070433ce3510918802a3bcce1 13704dc1c4aab2374a5fbfd5de45eba0eb7b128d c8f58541eeed5737b27b22855eed8cf67d44541a 0dac36ca2a71aec3224f3b195e055e799b734227 5e6c7fb196611594938560da2befcdd862fb3fd4 4bbc37c608b7517dba9e5665f1b4dbb1fec96157 5f26656bc6c2bcbd233071041729d9a5ff677f34 a7d852ffb3609abddf82ba874ede763f7222e9b5 We cannot bisect more! terry@lynn-stretch:~/lo_hacking/bibisect/bibisect-50max$ git bisect log # bad: [dda106fd616b7c0b8dc2370f6f1184501b01a49e] source-hash-0db96caf0fcce09b87621c11b584a6d81cc7df86 # good: [5b9dd620df316345477f0b6e6c9ed8ada7b6c091] source-hash-2851ce5afd0f37764cbbc2c2a9a63c7adc844311 git bisect start 'latest' 'oldest' # bad: [0c30a2c797b249d0cd804cb71554946e2276b557] source-hash-45aaec8206182c16025cbcb20651ddbdf558b95d git bisect bad 0c30a2c797b249d0cd804cb71554946e2276b557 # good: [770ff0d1a74d2450c2decb349b62c5087e12c46b] source-hash-549b7fad48bb9ddcba7dfa92daea6ce917853a03 git bisect good 770ff0d1a74d2450c2decb349b62c5087e12c46b # bad: [259e888083cf7697956bb7e5f2691e8153eadb4c] source-hash-1884c0bbd40f0ded41d7a1656cb64fb1f6368c36 git bisect bad 259e888083cf7697956bb7e5f2691e8153eadb4c # good: [ee7c82541a2e99f76af570d3faa897504149913a] source-hash-54defd1bd3359c95e45891c7294847d0cebca753 git bisect good ee7c82541a2e99f76af570d3faa897504149913a # bad: [504f60cf9ee84da75d4c15a62dedb18976129c14] source-hash-c8af68bc5adf093f9df803f6fe0147ac9d116169 git bisect bad 504f60cf9ee84da75d4c15a62dedb18976129c14 # good: [00c3cacafec11fdfbdf7f0c8c279503cd109d8a0] source-hash-f21114332bf670ab7f8e9b0a7f4d83d436d8fd9e git bisect good 00c3cacafec11fdfbdf7f0c8c279503cd109d8a0 # good: [5e1da738abc9f023f0c7bafcffc10d899b57a95b] source-hash-ef296e87b8afa1afdc08a23675658e0252dd2b86 git bisect good 5e1da738abc9f023f0c7bafcffc10d899b57a95b # bad: [4f494de6bc4e4807e40cb0793c3f18b029cab36d] source-hash-35f70c86f2d75cca18a34b2290a71753b3910879 git bisect bad 4f494de6bc4e4807e40cb0793c3f18b029cab36d # skip: [c8f58541eeed5737b27b22855eed8cf67d44541a] source-hash-8419fa8c28dd9c5f64a72d28d561b3817d781232 git bisect skip c8f58541eeed5737b27b22855eed8cf67d44541a # good: [0b0db851d65730a5d8f363651d37c1b045782832] source-hash-5d47b83cef0b2d0486162989722b23e53eb0cdb1 git bisect good 0b0db851d65730a5d8f363651d37c1b045782832 # skip: [5fd8a74fb9ca7ad070433ce3510918802a3bcce1] source-hash-0442cd217645aa4fdd924e4c2e4f90a77f1fbbad git bisect skip 5fd8a74fb9ca7ad070433ce3510918802a3bcce1 # bad: [a7d852ffb3609abddf82ba874ede763f7222e9b5] source-hash-ad50b9a8636e0ee2f3c80669e8dde96577b26c4e git bisect bad a7d852ffb3609abddf82ba874ede763f7222e9b5 # good: [ab2030ba105fad184edc6a2c02cc77aacccfb9ba] source-hash-d9b45d0823a5f2af89f5e60862711648beeebfb2 git bisect good ab2030ba105fad184edc6a2c02cc77aacccfb9ba # skip: [0dac36ca2a71aec3224f3b195e055e799b734227] source-hash-9964b4087924777d2bd585a5d6ce5c088ef65b65 git bisect skip 0dac36ca2a71aec3224f3b195e055e799b734227 # good: [8d7a017c57d61ac1b644554e8f5a4882e1fb22ff] source-hash-853c2fc71a96755a9dee629fd5d0e1cff9a48034 git bisect good 8d7a017c57d61ac1b644554e8f5a4882e1fb22ff # skip: [5e6c7fb196611594938560da2befcdd862fb3fd4] source-hash-e753d31d5d2338da35b69b0a3b7742420c7562d2 git bisect skip 5e6c7fb196611594938560da2befcdd862fb3fd4 # skip: [13704dc1c4aab2374a5fbfd5de45eba0eb7b128d] source-hash-05e7b1db351ee964d155e49c55de7db3c917083f git bisect skip 13704dc1c4aab2374a5fbfd5de45eba0eb7b128d # skip: [4bbc37c608b7517dba9e5665f1b4dbb1fec96157] source-hash-4c752c44f8a0857c4f2dbd61aff6b2d10cf3b5e5 git bisect skip 4bbc37c608b7517dba9e5665f1b4dbb1fec96157 # skip: [5f26656bc6c2bcbd233071041729d9a5ff677f34] source-hash-fcecc1fcb4a971a08d1e1fa5767bc5d93393a504 git bisect skip 5f26656bc6c2bcbd233071041729d9a5ff677f34 # only skipped commits left to test # possible first bad commit: [a7d852ffb3609abddf82ba874ede763f7222e9b5] source-hash-ad50b9a8636e0ee2f3c80669e8dde96577b26c4e # possible first bad commit: [5f26656bc6c2bcbd233071041729d9a5ff677f34] source-hash-fcecc1fcb4a971a08d1e1fa5767bc5d93393a504 # possible first bad commit: [5e6c7fb196611594938560da2befcdd862fb3fd4] source-hash-e753d31d5d2338da35b69b0a3b7742420c7562d2 # possible first bad commit: [13704dc1c4aab2374a5fbfd5de45eba0eb7b128d] source-hash-05e7b1db351ee964d155e49c55de7db3c917083f # possible first bad commit: [5fd8a74fb9ca7ad070433ce3510918802a3bcce1] source-hash-0442cd217645aa4fdd924e4c2e4f90a77f1fbbad # possible first bad commit: [c8f58541eeed5737b27b22855eed8cf67d44541a] source-hash-8419fa8c28dd9c5f64a72d28d561b3817d781232 # possible first bad commit: [0dac36ca2a71aec3224f3b195e055e799b734227] source-hash-9964b4087924777d2bd585a5d6ce5c088ef65b65 # possible first bad commit: [4bbc37c608b7517dba9e5665f1b4dbb1fec96157] source-hash-4c752c44f8a0857c4f2dbd61aff6b2d10cf3b5e5 I am removing keyword bibisectRequest and adding bibisected.
The specific commit was https://cgit.freedesktop.org/libreoffice/core/commit/?id=162c72d64077d9e0dae820d881ce2b56a5b2040c author Caolán McNamara <caolanm@redhat.com> 2015-01-23 13:17:39 (GMT) Related: fdo#78599 ensure RegisterFormat is called before SetModified and the related https://cgit.freedesktop.org/libreoffice/core/commit/?id=ad50b9a8636e0ee2f3c80669e8dde96577b26c4e Related: fdo#78599 wrong method [where rNdTbl.RegisterToFormat(*pTableFmt) was added to the wrong ::TextToTable] There are 4 ::TextToTable functions in here. It looks like it was removed from SwDoc::TextToTable( const SwInsertTableOptions& rInsTblOpts, and added to SwNodes::TextToTable( const SwNodes::TableRanges_t & rTableNodes, CC Caolán
(In reply to Justin L from comment #21) > There are 4 ::TextToTable functions in here. It looks like it was removed > from > SwDoc::TextToTable( const SwInsertTableOptions& rInsTblOpts, > and added to > SwNodes::TextToTable( const SwNodes::TableRanges_t & rTableNodes, bad conclusion. It was removed from both SwDoc::TextToTables, and added to both SwNodes::TextToTables. In this particular document, it first goes through SwNodes::TextToTable, and then SwDoc::TextToTable. Registering earlier in SwNodes results in the regression demonstrated in this bug.
Adding Cc: to Caolán McNamara
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c117ab838b49b355a3f3fa48632a43284c989ffa Resolves: tdf#103938 replace fix for tdf#78599/tdf#87977 It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
backports will follow
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7bc3175ad1fddf71c2a0108541e538f82872579a&h=libreoffice-5-3 Resolves: tdf#103938 replace fix for tdf#78599/tdf#87977 It will be available in 5.3.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I see the bug is fixed in daily Linux dbgutil bibisect repository version 2016-12-14.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a4d4fbeb623013f6377b30711ceedb38ea4b49f8&h=libreoffice-5-2 Resolves: tdf#103938 replace fix for tdf#78599/tdf#87977 It will be available in 5.2.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.