Created attachment 142466 [details]
Sample

(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

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

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.

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

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

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.

Or C
Do not use SetLogicRect() at all, but resize via transformation matrix or via Resize() in all cases.

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

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.

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.

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.

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.

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

Set to verify according comment #17