Bug 1678319

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.

"1. Update libreoffice to version 6.1.2.1-7.fc30 or 6.2.0.3-1.fc30"

is that suggesting that 6.1.2.1-6.fc30 was ok, what is the version it was upgraded from ?

And what is the font used in the spreadsheet ?

(In reply to Caolan McNamara from comment #2)
> "1. Update libreoffice to version 6.1.2.1-7.fc30 or 6.2.0.3-1.fc30"
> 
> is that suggesting that 6.1.2.1-6.fc30 was ok, what is the version it was
> upgraded from ?

No. The documents opened correctly before 6.1.2.1-6.fc30.  I thought the next update will resolve the anomaly, so I updated to 6.2.0.3-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.

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 ?

 (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;

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

I'm almost certain its not any modification on our side. Something has gone wrong in toolchain or dependency chain is my guess

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?

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

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.

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

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.

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.

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.

(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.

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 ?

(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: 6.0.3.2).  It opens well in 6.2.0.3-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.

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.

Can you attach something which reproduces the problem ?

Created attachment 1537870 [details]
document being recreated now misbehaves too

The attached document was created this morning using Libreoffice (6.2.0.3-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 6.2.0.3-3

Tested with Libreoffice in fc29 Live media (USB).  Everything worked fine.  Its confirmed -- a bug was introduced from 6.1.2.1-7.fc30 and is active in  6.2.0.3-1.fc30.

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.

recompiling the files that have include mdds headers with -O0 works, recompiling with -O2 results in mangled stuff

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

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-6.2.0.3-4.fc30

I have tested libreoffice-6.2.0.3-4.fc30.  So far, it works well with the test-docs.  You need any karma on this?

libreoffice-6.2.1.2-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-5ce355a5a7

libreoffice-6.2.1.2-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

libreoffice-6.2.1.2-2.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.