Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
|Summary:||Libreoffice-calc alters cell-widths when opening a saved spreadsheet file.|
|Product:||[Fedora] Fedora||Reporter:||Onyeibo Oku <twohot>|
|Component:||libreoffice||Assignee:||Caolan McNamara <caolanm>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||30||CC:||caolanm, dtardon, erack, pnemade, sbergman, twohot|
|Fixed In Version:||libreoffice-22.214.171.124-4.fc30 libreoffice-126.96.36.199-2.fc30||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2019-03-29 19:11:08 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1682941|
Description Onyeibo Oku 2019-02-18 13:48:56 UTC
Comment 1 Parag Nemade 2019-02-18 14:12:58 UTC
Thanks Onyeibo for reporting this bug. Just sharing my feedback based here :) I recently upgraded my F29 system to F30. I was having one spreadsheet which I worked on in F29. Now after upgrade when I opened it, I was having a table of something like 13 rows x 7 columns. I specifically adjusted the column width as per the max text in one of the cells. Now on F30, I saw some columns got width reduced and some increased. I just resize them to look it like previous state. The only change is new libreoffice package on F30.
Comment 2 Caolan McNamara 2019-02-18 15:04:45 UTC
"1. Update libreoffice to version 188.8.131.52-7.fc30 or 184.108.40.206-1.fc30" is that suggesting that 220.127.116.11-6.fc30 was ok, what is the version it was upgraded from ? And what is the font used in the spreadsheet ?
Comment 3 Onyeibo Oku 2019-02-18 22:15:08 UTC
(In reply to Caolan McNamara from comment #2) > "1. Update libreoffice to version 18.104.22.168-7.fc30 or 22.214.171.124-1.fc30" > > is that suggesting that 126.96.36.199-6.fc30 was ok, what is the version it was > upgraded from ? No. The documents opened correctly before 188.8.131.52-6.fc30. I thought the next update will resolve the anomaly, so I updated to 184.108.40.206-1.fc30. The problem persisted > > And what is the font used in the spreadsheet ? Most affected cells bear Deja Sans Mono font. However, I have seen similar issues in cells bearing Open Sans and Arial. I have just observed that Libreoffice-Calc opens and displays data in backup copies properly, i.e. where they were stored with the XLS format. Hence, If I had saved a spreadsheet session as "XYZ.ods", and saved a copy as "XYZ.xls", the .ods file exhibited the issue while the .xls version displayed correctly. Note: The test documents were created in September 2018.
Comment 4 Caolan McNamara 2019-02-19 09:15:53 UTC
hmm... * Wed Nov 14 2018 Rex Dieter <rdieter> - 1:6.1.2-6 - -kf5 subpackage: include support for --enable-gtk3-kde5 (#1647233) I wonder if building with --enable-gtk3-kde5 has some relation to this problem. Under help->about libreoffice-> What does the third line, ending in "VCL: something" say ?
Comment 5 Onyeibo Oku 2019-02-19 19:32:11 UTC
(In reply to Caolan McNamara from comment #4) > I wonder if building with --enable-gtk3-kde5 has some relation to this > problem. Under help->about libreoffice-> What does the third line, ending in > "VCL: something" say ? CPU threads: 4; OS: Linux 5.0; UI render: default; VCL: gtk3;
Comment 6 Onyeibo Oku 2019-02-20 06:16:59 UTC
I removed all Libreoffice packages that came from the Rawhide Repository and tested those from: https://download.documentfoundation.org/libreoffice/stable/6.2.0/rpm/x86_64/LibreOffice_6.2.0_Linux_x86-64_rpm.tar.gz.torrent Result: All documents opened correctly This issue appears to be exclusive to Fedora
Comment 7 Caolan McNamara 2019-02-20 08:54:00 UTC
I'm almost certain its not any modification on our side. Something has gone wrong in toolchain or dependency chain is my guess
Comment 8 Onyeibo Oku 2019-02-20 10:23:39 UTC
It gets more interesting. After successfully opening the calc documents with Libreoffice (from TDF, http://documentfoundation.org/), I discovered that Python scripts no longer load certain modules (e.g the 'import sqlite3' statement). However, the offending import statement works in the Python Interpreter, which confirms that the $PYTHONPATH is properly setup). This prompted me to remove $HOME/.config/libreoffice (user profile). Libreoffice from TDF (documentfoundation.org/) failed to recreate the user-profile while the system version succeeded in recreating it. Afterwards, the system Libreoffice continued to exhibit the issue reported in this Bug report. The TDF libreoffice no longer start (throws an error: X server found. dri2 connection failed!). Summary -- the version from TDF formats the documents as expected but it will *not* start after ours recreated the user-profile. Our Libreoffice still does *NOT* format the documents correctly. Where do I start troubleshooting?
Comment 9 Caolan McNamara 2019-02-20 10:40:06 UTC
TDF libreoffice comes with its own internal copy of python, which doesn't include the full set of modules available with system python used by the Fedora build TDF libreoffice probably isn't starting because of bug #1432468 which never got fixed in fedora so by default opencl is disabled in the fedora build to workaround it. IIRC you can start it with --safe-mode and disable opencl through that in order to bodge the TDF build into starting wrt the rendering differences, its possible that there is some font problem, and the TDF build comes with copies of fonts so the difference might be due to that
Comment 10 Onyeibo Oku 2019-02-20 12:34:28 UTC
Created attachment 1536681 [details] opening-sample-document-with-system-libreoffice system Libreoffice opens document but alters cell-widths and reveals hidden cells. Take note of rendition of fonts.
Comment 11 Onyeibo Oku 2019-02-20 12:37:51 UTC
Created attachment 1536682 [details] opening-xls-backup-version-with-system-libreoffice System Libreoffice opens the XLS (Excel) format of the same document Created with "Save-As --> Excel-2003" from the ODS file. System Libreoffice views the document correctly. Note the rendition of the fonts
Comment 12 Onyeibo Oku 2019-02-20 12:40:46 UTC
Created attachment 1536684 [details] opening-sample-document-with-libreoffice-from-TDF Libreoffice from documentfoundation.org opens the sample document correctly (preserves saved cell-widths, and retains hidden columns). Note the rendition of the fonts.
Comment 13 Onyeibo Oku 2019-02-20 12:47:28 UTC
From the screenshots (see attachments), it is doubtful that this is something to do with Font rendition since the system's Libreoffice presents the fonts and cells as intended with the XLS format. Only the Open Spreadsheet format is affected. The System's Libreoffice does not present cells as originally stored, whereas the TDF Libreoffice views it correctly. Something in the current Libreoffice (system) is altering the cell formats/states.
Comment 14 Eike Rathke 2019-02-20 18:15:52 UTC
So this is actually not about cell widths but hidden columns instead, i.e. in the first attachment 1536681 [details] (.ods in system build) vs the other two (.xls in system build and .ods in TDF build) columns displayed are G J K L O P S T U V (bad) G K L M N Q R V (good) Makes no sense to me.
Comment 15 Onyeibo Oku 2019-02-20 20:18:43 UTC
(In reply to Eike Rathke from comment #14) > So this is actually not about cell widths but hidden columns instead, i.e. It is also about cell-widths because i have other documents without hidden columns where the widths were altered (some cells became significantly wider, making the layout too long for the paper). The attached sample included hidden cells. > in the first attachment 1536681 [details] (.ods in system build) vs the > other two (.xls in system build and .ods in TDF build) columns displayed are > > G J K L O P S T U V (bad) > > G K L M N Q R V (good) > > Makes no sense to me. I explain: 1. Column-K is a little wider than was stored. Column-V is much wider than was stored. Compare with the "good" ones (expected display) 2. All the Hidden columns were not supposed to show -- they should remain hidden 3. Columns O,P,S,U are actually wider than designed & stored (Assuming the user toggled them to show, their widths should be smaller than currently displayed) 4. Columns L,M,N,Q,R should be clearly displayed and not partially or completely hidden.
Comment 16 Caolan McNamara 2019-02-21 09:39:21 UTC
Creating a trivial example in F29 with hidden columns and explicitly narrowed column widths, and opening it in a (freshly installed) F30 install, doesn't reproduce it for me. Can I get a sample .ods that definitely reproduces this ?
Comment 17 Onyeibo Oku 2019-02-22 10:31:04 UTC
(In reply to Caolan McNamara from comment #16) > Creating a trivial example in F29 with hidden columns and explicitly > narrowed column widths, and opening it in a (freshly installed) F30 install, > doesn't reproduce it for me. Can I get a sample .ods that definitely > reproduces this ? Same here. I just created another document with similar formatting using a rawhide build of fc29 (libreoffice Version: 220.127.116.11). It opens well in 18.104.22.168-1.fc30. This is frustrating because I am sure there's an obvious change in document handling along the line. One thing I have noticed though, is that this anomaly happens with files created in September 2018 (between the 11th and 25th). Files created earlier, open correctly. Perhaps we should be testing with the version of Libreoffice that was in the repos within that period.
Comment 18 Onyeibo Oku 2019-02-22 13:46:25 UTC
Fixing the cell-widths on the affected documents and saving them back does *not* fix the problem. After editing the files and saving them, Libreoffice opens them with altered cell-widths. The XML structure of these files may have been corrupted by a previously packaged version of Libreoffice. In any case, there's something embedded by an earlier version that recent versions are unable to interpret.
Comment 19 Caolan McNamara 2019-02-22 14:10:23 UTC
Can you attach something which reproduces the problem ?
Comment 20 Onyeibo Oku 2019-02-23 14:02:38 UTC
Created attachment 1537870 [details] document being recreated now misbehaves too The attached document was created this morning using Libreoffice (22.214.171.124-1.fc30) from Rawhide. It is an attempt to recreate one of the affected documents. The recreation process revealed suspicious behaviours. The handling of cell-padding seems erratic (see C12:F12--> cells still show a padding on the right despite a value of zero). More seriously, Columns C to G with widths that were explicitly set to 2.0cm did not display correctly in subsequent Libreoffice sessions. Columns C to G stubbornly defaults to 2.26cm despite several revisions and saves. However, Libreoffice from TDF (documentfoundation.org) displays those column-widths correctly. This time around, the test-document was created with the recent Libreoffice in the repos. TDF's Libreoffice handles the document better. Why is this? Note: The version of Libreoffice from TDF used for this comparison is 126.96.36.199-3
Comment 21 Onyeibo Oku 2019-02-24 05:58:01 UTC
Tested with Libreoffice in fc29 Live media (USB). Everything worked fine. Its confirmed -- a bug was introduced from 188.8.131.52-7.fc30 and is active in 184.108.40.206-1.fc30.
Comment 23 Caolan McNamara 2019-02-25 09:15:57 UTC
I have a reproducer and can verify the problem. The why is still unknown for the moment. There isn't any specific mods on the fedora side. Its the same mdds and liborcus versions in upstream as used downstream. The boost version change was a month after the first build where the problem began.
Comment 24 Caolan McNamara 2019-02-25 13:16:08 UTC
recompiling the files that have include mdds headers with -O0 works, recompiling with -O2 results in mangled stuff
Comment 25 Caolan McNamara 2019-02-25 14:13:59 UTC
touching sc/inc/mtvelements.hxx and building with -O1 is ok, -O2 fails. Interestingly if I build with -O1 and paste in all the extra options that gcc's help suggests are in O2 over O1 it works fine, while O2 fails
Comment 26 Caolan McNamara 2019-02-25 21:42:01 UTC
looks like a miscomplilation to me, reducing opt level from -O2 to -O1 for sc/source/filter/xml/xmlcoli.cxx fixes it, and/or massaging the code a little. I can bodge around this particular instance, but presumably there may be more. So reported as bug 1682941 for the general case, and I'll trying bodging it for this specific case as libreoffice-220.127.116.11-4.fc30
Comment 27 Onyeibo Oku 2019-03-02 06:20:18 UTC
I have tested libreoffice-18.104.22.168-4.fc30. So far, it works well with the test-docs. You need any karma on this?
Comment 28 Fedora Update System 2019-03-08 09:00:35 UTC
libreoffice-22.214.171.124-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-5ce355a5a7
Comment 29 Fedora Update System 2019-03-08 19:45:27 UTC
libreoffice-126.96.36.199-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-5ce355a5a7
Comment 30 Fedora Update System 2019-03-29 19:11:08 UTC
libreoffice-188.8.131.52-2.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.