search

CollaboraOnline / online

Collabora Online is a collaborative online office suite based on LibreOffice technology. This is also the source for the Collabora Office apps for iOS and Android.
https://collaboraonline.com
Other
1.79k stars 682 forks source link

Collabora Calc save re-opens in Libre at 200% zoom #4250

Open LorenAmelang opened 2 years ago

LorenAmelang commented 2 years ago

Describe the bug I use Libre Office on Windows. Just got a new iPad Pro 12.9, and happened across Collabora. The calc documents live in iCloud, accessible on both. If I edit one in Collabora, it gets saved looking the same size as it opened. But when I next open it in Libre, it opens with the zoom slider at 200%. And showing cell A1 instead of the last line where I just entered new data.

To Reproduce Save a sheet in Libre, it reopens in Libre at the bottom row with the last chosen zoom setting. Open it in Collabora, on iPhone or iPad, and it opens at row 1, at a normal zoom. Save and re-open in Collabora and it looks exactly the same. Re-open it in Libre, in Linux or Windows, and it opens at row 1 at 200% zoom.

Expected behavior After editing a file in Collabora, it should re-open in Libre at the previously chosen zoom, normally 100%. And at the last viewed row of the sheet.

Actual behavior Collabora saved sheets re-open in Libre at 200% zoom. And do not preserve the last viewed row location...

Surprisingly, this is not a problem for Excel, at least my 2016 version that refuses to authorize any more. It opens the Collabora file at 100% zoom.

Screenshots Test files: Collabora Test Libre save.ods Collabora Test Collab save.ods

Desktop (please complete the following information)

Smartphone (please complete the following information)

Additional context Not a huge problem, but a repeating hassle… I have no idea what might be getting changed to cause this. The Windows machine uses Microsoft screen scaling at 200%, but Libre deals with that properly. The iPad uses extra large type, but again I’ve never seen that affect any other app.

For the test file, the Libre save is 9,884 bytes, Collabora save is 7,220 bytes. For a larger file, 370 lines with two columns, the difference is 48,925 bytes to 27,913 bytes! The re-save in Libre takes it back to 49K bytes

Peeking at a diff of the two files, the Libre save begins with "PK ... a?ST?l9?." and has 34 instances of "ST". The Collabora save begins with "PK ... "QT?l9?." and has 34 instances of "QT". Does "QT" refer to QT5? Might that matter?

The majority of the content lines show differences... Far beyond my ability to guess what they mean.

Is there some way to make this friendlier?

rpear commented 2 years ago

The zoom level is zoom 200% for me too, when opened in LibreOffice 7.3 on Windows. The same file is zoom 100% if I open it in Collabora Office App 6.4.14 on a Chromebook. The same file is zoom 100% if I open it in LibreOffice 6.1 running on Chromebook Linux.

pedropintosilva commented 2 years ago

Thanks @LorenAmelang for reporting it and @rpear for testing it as well

monochromec commented 1 year ago

Continuing @LorenAmelang 's initial RCA, a further analysis of the two ODS files (which essentially are zip files based on an OpenDocument standard) reveals a difference in the settings.xml file in the lop-level directory of the uncompressed zip archive:

Original ODS file:

<config:config-item config:name="ZoomValue" config:type  e="short">0</config:config-item><config:config-item config:name="ZoomValue" config:type
="int">75</config:config-item>

Same ODS download after modification by Collabora Calc:

<config:config-item config:name="ZoomValue" config:type  e="short">0</config:config-item><config:config-item config:name="ZoomValue" config:type
="int">200</config:config-item>

This config value is repeated a few times in the XML file. A cursory inspection of the CB in the light of this RCA remains inconclusive. Please let me know if more info is needed.

monochromec commented 1 year ago

Upon further analysis, the problem in the corresponding CODE appimage seems to be a library called libsclo.so, a core component of LO itself. Analysing the LO CB further, apparently the ZoomValue is handled in the C++ file viewdata.cxx (in sc/source/ui/view of the LO core repo).

As the original LO implementation works w/o issues, I suspect a packaging / patching issue by the CODE devs as part of the AppImage build process rather than upstream so it would be great a Collabora dev could take a look at this issue as this is becoming more and more of a nuisance. @pedropintosilva Is this an option?

monochromec commented 1 year ago

Any progress on this? As this issue has been open for almost a year now with little progress.

LorenAmelang commented 1 year ago

I'm also surprised this has dropped off the radar. It seemed to get some Collabora Meeting attention at first... It still happens whenever I change a file in Collabora. File size drops (190.9K to 175.8K today), Libre then shows it at 200%, and opens it at the top rather than the last edit at the bottom. I noticed Collabora opens the file at the top, but clicking the Edit icon moves the view to the last edit at the bottom. Maybe it saves that point but doesn't write it where Libre expects it? Libre opens with editing live...

jenspeternielsen commented 1 year ago

Nextcloud AIO Collabora/code 22.05.10.8.1 (Nextcloud Office) OOXML

Senarios:

  1. I create a new sheet in Nextcloud Office.

    • Zoom shows 100% in Nextcloud Office.
    • edit and save in Nextcloud Office 1a. I check what is written to the xml file! zoomScale="200" zoomScaleNormal="200" zoomScalePageLayoutView="100" (this is wrong.....) If I open the same sheet in LibreOffice / MS Excel - it wil as expected - open the sheet in 200%.

  2. I create a new sheet in Nextcloud Office.

    • I change Zoom to 50% in Nextcloud Office.
    • edit and save in Nextcloud Office 2a. check what is written to the xml file! zoomScale="96" zoomScaleNormal="96" zoomScalePageLayoutView="100" (this is wrong....) If I open the same sheet in LibreOffice / MS Excel - it wil as expected - open the sheet in 96%.

In Nextcloud Office - whatever the zoom factor is set to before saved - allways opens in 100%

Conclusion: The zoom funktion / or what is written to the xml file when you are saving a document - is buggy in Collabora/code 22.05.10.8.1 (Nextcloud Office).

monochromec commented 1 year ago

Excellent - another justification for this getting looked at (cf. my RCA dated 12/23/2022). Unfortunately this doesn't seem to get any traction as nobody / no dev is looking at this. I may dive a little bit deeper into this once my bandwidth allows me too.

arnowelzel commented 1 year ago

I can confirm this behaviour - when modifying a document on a screen which uses 200% scaling. Unfortunately I have neither the time nor the required knowledge to help here.

arnowelzel commented 11 months ago

Any progress on this? This issue is still a problem and quite annoying when you always have to manually change the zoom back to 100% when anyone edited the document online with a 200% scaling browser.

monochromec commented 11 months ago

Given the really slow progress of resolving this issue (despite my initial RCA, see hints above), the focus of the project seems to be on new feature commits rather that resolving existing issues (supported by the fact that this repo has 236 open issues which do not have the label "unconfirmed" attached to them, the oldest being just under three years old at the time of writing).

:-((

arnowelzel commented 11 months ago

I am willing to sponsor a fix for this issue financially to a certain degree if this can speed up things.

LorenAmelang commented 11 months ago

@monochromec

Given the really slow progress of resolving this issue (despite my initial RCA, see hints above), the focus of the project seems to be on new feature commits rather that resolving existing issues (supported by the fact that this repo has 236 open issues which do not have the label "unconfirmed" attached to them, the oldest being just under three years old at the time of writing).

Given the lack of fixes for this and other issues I've encountered, I've abandoned Collabora. It is far more efficient to wake and VNC into the Linux system than to struggle with an app that is so close to great but always disappoints.

arnowelzel commented 8 months ago

I just checked the behaviour with Collabora 23.05.6.5 CODE - still the same problem, after nearly 2(!) years!

monochromec commented 8 months ago

Unfortunately (despite the financial incentive) the project seems to have other priorities. I tried to reach out to a couple of the devs, but just received nothing but radio silence. Perhaps @LorenAmelang does have a point...

arnowelzel commented 8 months ago

Unfortunately (despite the financial incentive) the project seems to have other priorities.

Yes, seems so. I finally stopped using Collabora at all. I have about 75 users here and I can not afford to explain this bug over and over again to them. That's a pity, since LibreOffice works quite well and having issues like this fuels the peoples mistrust in open source projects :-(

And yes, I am still willing to pay for a solution to this! If anyone wants to work on that and can come up with a fix, I will donate for this.

mikekaganski commented 7 months ago

The problem here is:

  1. Collabora Online sets zoom in the core based on the ratio of tile size (in pizel) to the twip size of the square. Naturally, this is based on pixel size, and the latter depends on PPI of the device.
  2. The zoom data is calculated in client, and sent to core using _sendClientZoom function. This packet does not include an information about the percepted zoom value, nor about the device PPI; hence, the core will get the same request from a device using 150 PPI screen + 200% zoom level, and from device with 300 PPI screen and 100% zoom level.
  3. In the end, the resulting artificial (technical) zoom level will be dully stored by core into the file (ScViewData(Table)::WriteUserDataSequence in sc/source/ui/view/viewdata.cxx).
  4. Collabora Online ignores the stored zoom values, hence it is unaffected by the problem.

A simple workaround would be to not store the zoom level at all in LOK case. This would not fix the issue properly, just it wouldn't be "random" zoom when opened on desktop, only unconditional 100% zoom.

A better change would be also sending correct zoom level with the message; storing it in the LOK-specific view data would allow to special-case the store procedure, which in LOK case would store that value. This would also allow Online eventually to benefit from the stored zoom, in interoperable way.

Tex2002ans commented 7 months ago

Definitely seems like the "root cause" is:

Maybe based on:

Potential Bibisection???

I stumbled across this COOL change from 2020, which seems promising:

Latest Confirmation

I also confirm @rpear's testing in Comment 1:

Still happening with the latest:

COOLWSD version: 23.05.8.4 (git hash: f1415b6c)
LOKit version: Collabora Office 23.05.8.4 (git hash: ad6ed50)
Served by: Linux Mint 21.1
Server ID: 7969692d
Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

I also confirm @monochromec's analysis in comment 3.

Those are the exact ZoomValue lines I came across as well when testing/ripping open the ODSs too:

(I also confirm similar odd mismatching "ZoomValues in ODS vs. Calc Zoom Slider" when creating a fresh ODS in Collabora 23.05 too.)

Summary

Somewhere along the line, it seems like Collabora's Calc is:

On Save

Like others have said, it could also have to do with a:

On Load

Side Note: I suspect that load issue may be intended + a little trickier too, because you can have multiple users with completely different:

all editing spreadsheets at the same time, so you wouldn't want some other user's:

More LO+Calc Resources (?)

With the help of @rpear's Comment 1 + @monochromec's Comment 5:

The zoom level is zoom 200% for me too, when opened in LibreOffice 7.3 on Windows. [...] The same file is zoom 100% if I open it in LibreOffice 6.1 running on Chromebook Linux.

and:

[...] the problem in the corresponding CODE appimage seems to be a library called libsclo.so, a core component of LO itself. Analysing the LO CB further, apparently the ZoomValue is handled in the C++ file viewdata.cxx (in sc/source/ui/view of the LO core repo).

I used that to skim:

Back in 2019—which was around LibreOffice 6.4—there was lots of "zoom-related work" going on by mmeeks and others:

Combined with that COOL change mentioned in very top of this post, perhaps that's around the time when this COOL regression accidentally got introduced.