Bug 117948 - After hiding a column, saving and reopening, line is moved to a different column
Summary: After hiding a column, saving and reopening, line is moved to a different column
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.4.7.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-01 05:36 UTC by Hidenori Ozaki
Modified: 2021-01-05 13:41 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample (9.01 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-06-01 05:38 UTC, Hidenori Ozaki
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hidenori Ozaki 2018-06-01 05:36:36 UTC
Description:
After hide a colum and save the file, some object position are moved when reopen it.This may is related to “Group and Outline” and “Anchor”.

Steps to Reproduce:
1. Open the attached file "bug2.ods".
2. Anchors of a circle and a line are seted to "To sell".
3. B column is grouped.
4. The circle and the line are on the "D" column.
5. Select B column, then "Format", "column", "hide". 
6. Save the file and close Calc. After that, reopen the file, "bug2.ods".

Actual Results:  
The position of the circle is not moved. But the position of the line is moved to column "C"

Expected Results:
I hope the position should not moved. 


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36
Comment 1 Hidenori Ozaki 2018-06-01 05:38:25 UTC
Created attachment 142466 [details]
Sample
Comment 2 Hidenori Ozaki 2018-06-01 05:42:10 UTC
(In reply to Hidenori Ozaki from comment #0)
> Description:
> After hide a colum and save the file, some object position are moved when
> reopen it.This may is related to “Group and Outline” and “Anchor”.
> 
> Steps to Reproduce:
> 1. Open the attached file "bug2.ods".
> 2. Anchors of a circle and a line are seted to "To sell".
> 3. B column is grouped.
> 4. Select B column, then "Format", "column", "hide".
> 5. The circle and the line are on the "D" column. 
> 6. Save the file and close Calc. After that, reopen the file, "bug2.ods".
> 
> Actual Results:  
> The position of the circle is not moved. But the position of the line is
> moved to column "C"
> 
> Expected Results:
> I hope the position should not moved. 
> 
> 
> Reproducible: Always
> 
> 
> User Profile Reset: No
> 
> 
> 
> Additional Info:
> 
> 
> User-Agent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like
> Gecko) Chrome/66.0.3359.181 Safari/537.36
Comment 3 Xavier Van Wijmeersch 2018-06-01 09:18:34 UTC
confirm with

Version: 5.0.6.3
Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa
Locale: en-US (en_US.UTF-8)

Version: 5.3.7.2
Build ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059
CPU Threads: 8; OS Version: Linux 4.14; UI Render: default; VCL: kde4; Layout Engine: new; 
Locale: nl-BE (en_US.UTF-8); Calc: group

Version: 5.4.1.2
Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group

Version: 6.1.0.0.beta1+
Build ID: e42f6174d30c9f2211bdaffdefb011eeb9ead1fc
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group threaded

no problem with Aoo snapshot 4.2.0
Comment 4 Buovjaga 2018-07-12 18:14:28 UTC
Was going to bibisect this, but in Linux 41max, the oldest commit shows both shapes in column D upon opening. Same for all the older commits in 43all repo, including oldest. Same for 3.3.0.

So if AOO 4.2.0 does not show the problem, they must have fixed something in the meanwhile.

The wild thing is, the latest master shows both shapes in column D as well! I have to open a new report for it.
Comment 5 Buovjaga 2018-07-12 18:30:55 UTC Comment hidden (obsolete)
Comment 6 Buovjaga 2018-07-12 18:39:02 UTC Comment hidden (obsolete)
Comment 7 Buovjaga 2018-07-14 17:45:11 UTC
Bah, no bibisecting needed as the problem has existed as long as the initial display of the file has been correct (was wrong in 4.3 still).
Comment 8 QA Administrators 2019-07-15 02:48:35 UTC Comment hidden (obsolete)
Comment 9 Regina Henschel 2019-11-28 22:31:01 UTC
The bug still exists in Version: 6.5.0.0.alpha0+ (x64)
Build ID: 800b6f095f95ccfb8a7ba9755292332bf97f97ad
CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
Locale: de-DE (en_US); UI-Language: en-US
Calc: threaded
Comment 10 Regina Henschel 2020-02-13 23:11:53 UTC
The problem is in RecalcPos() in https://opengrok.libreoffice.org/xref/core/sc/source/core/data/drwlayer.cxx?r=f147b160 starting from line #978. The comment indicates, that it assumes, that setting the LogicRect will resize the shape. That is the case for most shapes, but not for SdrPathObj. Here the size is contained in the coordinates of its points and not in maRect.
Therefore
#996  pObj->SetLogicRect(aFullRect);
does not change the shape
and
#1001  const tools::Rectangle aObjRect(pObj->GetSnapRect());
does not return the expected rectangle.

Possible solutions:
A
Handle SdrPathObj different in drwlayer.cxx. (Ideas: Use NbcResize() of the SdrPathObj or work on a copy of its maPathPolygon.)
B
Implement SetLogicRect for SdrPathObj so, that it resizes the shape. Currently it has no own implementation but uses the inherited one from SdrTextObj.

A longer comment of the problems with maRect is in comment #1729-#1747 in https://opengrok.libreoffice.org/xref/core/svx/source/svdraw/svdopath.cxx?r=1f625b3f

I'm not sure, which way would be better.
Comment 11 Regina Henschel 2020-02-13 23:22:37 UTC
Or C
Do not use SetLogicRect() at all, but resize via transformation matrix or via Resize() in all cases.
Comment 12 Regina Henschel 2020-02-14 12:48:01 UTC
Or D
Do not manipulate the shape at all. Get GeoStat from the shape and apply it via Rect2Poly to aFullRect and get the range of the created Polygon.

(I'm currently not actively working on this issue. I come across this while working on a different topic. I have put here, what I have found so far, so that it is not lost.)
Comment 13 Regina Henschel 2020-10-11 12:15:05 UTC
I have add to svdopath.hxx
    virtual void NbcSetLogicRect(const tools::Rectangle& rRect) override;
and to svdo.cxx 
    void SdrPathObj::NbcSetLogicRect(const tools::Rectangle& rRect)
    {
        NbcSetSnapRect(rRect);
    }
NbxSetSnapRect does the needed calculations and updates maRect. Because transformations are incorporated into the points in case of SdrPathObj, maRect and maSnapRect should be identical.
That solves the problem of the shift after hiding a row or column.

But lines have an additional problem: To get the anchor type "To cell (resize with cell)" it is needed to write the attributes table:end-cell-address, table:end-x and table:end-y to file. For the line itself the attributes svg:x1, svg:y1, svg:x2 and svg:y2 are written, which determine the start and end point of the line. The problem is, that the values, which are written to file, are inconsistent. The coordinates, which are calculated from the table:end* attributes are different from the coordinates given is svg:x2 and svg:y2.

With the above mentioned changes to SdrPathObj the table:end* attributes are correctly evaluated, which was not the case before. But older documents have wrong values in it. Therefore it would be necessary to have a kind of "repair" part for lines, which exchanges the wrong table:end* attributes with values suitable to the svg:x2 and svg:y2 attributes, on opening. And of cause make sure, that now correct values are written to file. I have no idea yet, how to solve that.
Comment 14 Regina Henschel 2020-11-04 22:21:30 UTC
In the meantime I have changed the way objects are initialized in case they are anchored 'resize with cell'. [https://cgit.freedesktop.org/libreoffice/core/commit/?id=1f0b3c7a40edfa81bbc7a58d123a6a2dfd83e4ca]. But it does not fix the problems with collapsed group.
Comment 15 Regina Henschel 2020-11-05 13:37:15 UTC
It is an export problem. The geometry of the shape needs to be so in file format, as if there are no hidden rows or columns. But currently the geometry considers hidden rows and columns. Therefore the transformation values are wrong. A conversion is missing.
Comment 16 Commit Notification 2020-11-10 11:13:44 UTC
Regina Henschel committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1cb6bb9576871ff5d56c9810ff1791abc3dd64fd

tdf#117948 Do not treat hidden rows as zero in ODF export

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 17 Buovjaga 2020-11-11 16:32:09 UTC
I verify Regina's fix

Arch Linux 64-bit
Version: 7.1.0.0.alpha1+
Build ID: 3d3180115be3b87e76189aea2031f0caa735dbb3
CPU threads: 8; OS: Linux 5.9; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 11 November 2020
Comment 18 Regina Henschel 2021-01-05 13:41:46 UTC
Set to verify according comment #17