Created attachment 204450 [details]
File in the video

Environment:

OS: Windows 11 64-bit

LibreOffice Stable: 25.8.3.2 (x86_64)

LibreOffice Beta: 26.2.0.0.alpha1+ (x86_64)

Locale/UI: Ukrainian / UI Ukrainian

User Profile: Not reset

Steps to Reproduce:

Open LibreOffice Draw.

Draw a line.

Set the line angle to 90.00° via the Properties panel or Format → Position and Size.

Save the document.

Reopen the document.

Check the line angle in the properties dialog.

Observed Results:

Stable version (25.8.3.2): Angle changed to values like 89.93°, 90.07°, 89.13° or 0.00°.

Beta version (26.2.0.0.alpha1+): Angle remained exactly 90.00°.

Expected Results:the line angle should remain exactly 90.00° after saving and reopening.

Reproducibility: Stable- Always. Alpha- Not reproduced.

Danat: comment 2 reported this is fixed in the unreleased version. Can you test with Win-x86_64@tb103-1-TDF from https://dev-builds.libreoffice.org/daily/master/current.html ? It installs separately.

(In reply to Buovjaga from comment #3)
> Danat: comment 2 reported this is fixed in the unreleased version. Can you
> test with Win-x86_64@tb103-1-TDF from
> https://dev-builds.libreoffice.org/daily/master/current.html ? It installs
> separately.

Yes, happens. Will change status to "new", but if you may, ask others to check the file in attachments

Let them see if after saving it changes or remains the same

ALSO IMPORTANT:

The program treats 90° and 0° as the same. It's like the same position, but different values. And 0° gets changed to 90° after saving. You definitely need to let the devs know of that irregularity

(In reply to Buovjaga from comment #3)
> Danat: comment 2 reported this is fixed in the unreleased version. Can you
> test with Win-x86_64@tb103-1-TDF from
> https://dev-builds.libreoffice.org/daily/master/current.html ? It installs
> separately.

Sorry, it's the opposite: 90° gets changed to 0°. But maybe it's also the other way around, I'm not too sure

The non-optimal instructions had mislead the tester in comment 2. Correct steps:

1. Open attachment 204450 [details]
2. Select drawing object "Line 7", for example by right-clicking its entry in the Navigator
3. Either in Sidebar Properties deck's Position and size section or Format - Text box and shape - Position and size, change rotation from 90,07 to 90.
4. Save and reload

Select Line 7 again and observe that the rotation has not stayed as 90.

In older versions, when using the dialog, saving was not even needed to see the issue.

In 4.3, the rotation started opening as 90,08 instead of 90 with commit e034fa4607dfc732eaa82261755193fd781a2aad
DOCX import: make sure rotation is not changed when we alter size

I examined the word/document.xml inside the unzipped .docx, but couldn't figure out where the rotation for Line 7 is defined. The general definition block starts with:

<mc:AlternateContent>
  <mc:Choice Requires="wps">
    <w:drawing>
      <wp:anchor behindDoc="0" distT="28575" distB="28575" distL="28575" distR="28575" simplePos="0" locked="0" layoutInCell="1" allowOverlap="1" relativeHeight="7">
        <wp:simplePos x="0" y="0"/>
        <wp:positionH relativeFrom="column">
          <wp:posOffset>6042660</wp:posOffset>
        </wp:positionH>
        <wp:positionV relativeFrom="paragraph">
          <wp:posOffset>360680</wp:posOffset>
        </wp:positionV>
        <wp:extent cx="635" cy="501015"/>
        <wp:effectExtent l="28575" t="28575" r="28575" b="28575"/>
        <wp:wrapNone/>
        <wp:docPr id="10" name="Line 7"></wp:docPr>

In the oldest commit of linux-43max repo, the rotation opened as 270.

Let's ask Miklós what he thinks.

(In reply to Buovjaga from comment #6)
> The non-optimal instructions had mislead the tester in comment 2. Correct
> steps:
> 
> 1. Open attachment 204450 [details]
> 2. Select drawing object "Line 7", for example by right-clicking its entry
> in the Navigator
> 3. Either in Sidebar Properties deck's Position and size section or Format -
> Text box and shape - Position and size, change rotation from 90,07 to 90.
> 4. Save and reload
> 
> Select Line 7 again and observe that the rotation has not stayed as 90.
> 
> In older versions, when using the dialog, saving was not even needed to see
> the issue.
> 
> In 4.3, the rotation started opening as 90,08 instead of 90 with commit
> e034fa4607dfc732eaa82261755193fd781a2aad
> DOCX import: make sure rotation is not changed when we alter size
> 
> I examined the word/document.xml inside the unzipped .docx, but couldn't
> figure out where the rotation for Line 7 is defined. The general definition
> block starts with:
> 
> <mc:AlternateContent>
>   <mc:Choice Requires="wps">
>     <w:drawing>
>       <wp:anchor behindDoc="0" distT="28575" distB="28575" distL="28575"
> distR="28575" simplePos="0" locked="0" layoutInCell="1" allowOverlap="1"
> relativeHeight="7">
>         <wp:simplePos x="0" y="0"/>
>         <wp:positionH relativeFrom="column">
>           <wp:posOffset>6042660</wp:posOffset>
>         </wp:positionH>
>         <wp:positionV relativeFrom="paragraph">
>           <wp:posOffset>360680</wp:posOffset>
>         </wp:positionV>
>         <wp:extent cx="635" cy="501015"/>
>         <wp:effectExtent l="28575" t="28575" r="28575" b="28575"/>
>         <wp:wrapNone/>
>         <wp:docPr id="10" name="Line 7"></wp:docPr>
> 
> In the oldest commit of linux-43max repo, the rotation opened as 270.
> 
> Let's ask Miklós what he thinks.

Do none of the things in this report happen in odt?

(In reply to Buovjaga from comment #6)

By the way, it may sometimes affect the actual angle. Most of the times it's barely noticeable, but sometimes can be noticed

It is noticeable from 2:05 how it is skewed - https://drive.google.com/file/d/1AJ-iAWCpZQswgaL-0OQsKH4nsxUS3WER/view?usp=sharing

(In reply to Danat from comment #7)
> Do none of the things in this report happen in odt?

I forgot that the effect is also observed when saving to ODT.

(In reply to Buovjaga from comment #9)
> (In reply to Danat from comment #7)
> > Do none of the things in this report happen in odt?
> 
> I forgot that the effect is also observed when saving to ODT.

Why did you mark Volodymyr's triaging as off-topic? I unmarked it

(In reply to Danat from comment #10)
> (In reply to Buovjaga from comment #9)
> > (In reply to Danat from comment #7)
> > > Do none of the things in this report happen in odt?
> > 
> > I forgot that the effect is also observed when saving to ODT.
> 
> Why did you mark Volodymyr's triaging as off-topic? I unmarked it

Because it's about Draw instead of Writer and he did not see the behaviour in 26.2. But it's true that it should be investigated as well. I will do it later.

(In reply to Buovjaga from comment #11)
> (In reply to Danat from comment #10)
> > (In reply to Buovjaga from comment #9)
> > > (In reply to Danat from comment #7)
> > > > Do none of the things in this report happen in odt?
> > > 
> > > I forgot that the effect is also observed when saving to ODT.
> > 
> > Why did you mark Volodymyr's triaging as off-topic? I unmarked it
> 
> Because it's about Draw instead of Writer and he did not see the behaviour
> in 26.2. But it's true that it should be investigated as well. I will do it
> later.

I don't reproduce the issue from comment 2 in Draw on Windows or Linux. Danat: can you reproduce it?

Version: 25.8.3.2 (X86_64)
Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e
CPU threads: 2; OS: Windows 11 X86_64 (build 26100); UI render: default; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

Arch Linux 64-bit
Version: 25.8.3.2 (X86_64) / LibreOffice Community
Build ID: 580(Build:2)
CPU threads: 8; OS: Linux 6.17; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
25.8.3-1
Calc: CL threaded

(In reply to Buovjaga from comment #6)
> I examined the word/document.xml inside the unzipped .docx, but couldn't
> figure out where the rotation for Line 7 is defined. The general definition
> block starts with:

For drawingML shapes in general, you have this markup <a:xfrm rot="..."> for rotation. It seems lines are special, since they just have 2 points, so when you save them, you can just give them a position and size, and that kind of determines the starting and ending point, or something like that.

> Let's ask Miklós what he thinks.

I *think* once these position/size/rotation problems happen, the root of the trouble is that you can't set these properties in a random order -- ideally you set up your transform matrix and you set that matrix only once during the import, I recall the xmloff/ import code for ODF does that. My thinking is that the DOCX import should do the same, I started to move towards that direction in commit 1bec1608a55c1b5096e7a9d06564c658bd5be1d5 (tdf#165132 DOCX import: fix unexpected rotation on entirely vertical line, 2025-02-26) already.

The ideal would be to do that in more cases, and see if this case would also benefit from such a change. But that requires investigating why the two tests from the above commit fail when doing this in general. Thanks.

(In reply to Buovjaga from comment #12)
> (In reply to Buovjaga from comment #11)
> > (In reply to Danat from comment #10)
> > > (In reply to Buovjaga from comment #9)
> > > > (In reply to Danat from comment #7)
> > > > > Do none of the things in this report happen in odt?
> > > > 
> > > > I forgot that the effect is also observed when saving to ODT.
> > > 
> > > Why did you mark Volodymyr's triaging as off-topic? I unmarked it
> > 
> > Because it's about Draw instead of Writer and he did not see the behaviour
> > in 26.2. But it's true that it should be investigated as well. I will do it
> > later.
> 
> I don't reproduce the issue from comment 2 in Draw on Windows or Linux.
> Danat: can you reproduce it?
> 
> Version: 25.8.3.2 (X86_64)
> Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e
> CPU threads: 2; OS: Windows 11 X86_64 (build 26100); UI render: default;
> VCL: win
> Locale: en-US (en_US); UI: en-US
> Calc: threaded
> 
> Arch Linux 64-bit
> Version: 25.8.3.2 (X86_64) / LibreOffice Community
> Build ID: 580(Build:2)
> CPU threads: 8; OS: Linux 6.17; UI render: default; VCL: kf6 (cairo+wayland)
> Locale: fi-FI (fi_FI.UTF-8); UI: en-US
> 25.8.3-1
> Calc: CL threaded

I'm sorry, I'm not a Draw guy. I am only scrutinising Writer, I have no resources for other projects