[Libreoffice-bugs] [Bug 117948] After hiding a column, saving and reopening, line is moved to a different column

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Sun Oct 11 12:15:05 UTC 2020


https://bugs.documentfoundation.org/show_bug.cgi?id=117948

--- Comment #13 from Regina Henschel <rb.henschel at t-online.de> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20201011/de150f33/attachment.htm>


More information about the Libreoffice-bugs mailing list