Description: When creating one of the following shapes: - Curve - Polygon - Polygon (45°) - Freeform Line An arbitrary rotation value is given to the object automatically. - This is inconsistent: the filled equivalent of these 4 shape types do not get a rotation automatically assigned. - This is unexpected: why is a new object already "rotated"? - This is inconvenient: for example, if one writes text in the shape, one would expect it to be horizontal by default. It follows that arbitrary rotation instead. (see attached document for examples) Steps to Reproduce: 1. Open Draw 2. Choose one of the unfilled "shapes and polygons" 3. Draw several examples of random shapes 4. Observe the rotation value in "Properties sidebar > Line" section (or "Right-click > Position and Size..." for a Polygon) Actual Results: A rotation is given to a new object. Expected Results: No rotation is assigned to a new object. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.0.2.2 (x64) Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: default; VCL: win Locale: en-AU (en_AU); UI: en-US Calc: threaded
Created attachment 167066 [details] examples of shapes and text in shapes
Also confirmed with: Version: 7.1.0.0.alpha0+ Build ID: c7caec046f8bfff8c46fc930738f29631cf16df9 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-10-24_14:53:01 Calc: threaded One issue I have with this bug's consequences is that I can't figure out how to make the text horizontal again, without rotating the corresponding shape.
Thank you for reporting the bug. I tried reproducing the bug, I'm not getting any rotation value for Polygon (45°), Freeform Line and getting rotation value for Curve, Polygon about text: It is not following arbitrary rotation, it stays horizontal by default for all non filled shapes reproduced the bug in Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Version: 7.2.0.0.alpha0+ (x64) Build ID: 761a672d62df1891b9f4f367a499b220ab2b33fa CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Thanks for testing, Mulla. About not being able to reproduce for Polygon 45° or Freeform: could you please try again? It sometimes takes a few tries. If you draw something quite vertical with Polygon 45°, and something that follows the diagonal of the page with Freeform, I believe you should be able to reproduce. The Polygon 45° shape will often have the rotation 270°. See for example the new screenshot attached, tested with: Version: 7.0.3.1 Build ID: 00(Build:1) CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Ubuntu package version: 1:7.0.3-0ubuntu0.18.04.1 Calc: threaded You can see in the screenshot the text rotation for both shapes. Also confirmed with: Version: 7.1.0.0.beta1 Build ID: 828a45a14a0b954e0e539f5a9a10ca31c81d8f53 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Created attachment 167847 [details] screenshot of Freeform and Polygon 45° shapes Freeform and Polygon 45 both might have a rotation when created; text follows that rotation (LO 7.0.3 on Linux)
Still reproducible as described with: Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: 4a9eef7849a75ba91806886ea9c96d114c8d56f9 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-05-22_06:45:25 Calc: threaded
Reproduced in 6.2 as well, so issue has been around for a while. Version: 6.2.5.2 Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded
(In reply to stragu from comment #0) > Description: > When creating one of the following shapes: > > - Curve > - Polygon > - Polygon (45°) > - Freeform Line > > An arbitrary rotation value is given to the object automatically. I cannot confirm it for these shapes using Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4ac9032163cf55c160145373e7c41741c9c339ca CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL The rotation exists for straight lines. But it is not "arbitrary". It is the angle of the line. The purpose it, that text in such line follows the line.
Created attachment 176881 [details] example document reproducing the bug with LO 7.4 alpha0+ Thanks for re-testing, Regina, but I can still reproduce for the four shape types with: Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 06ac18e6302d666c363740644a7976e8c22d1113 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded (2021-12-12 build) In the attached document, the rotation value was automatically applied when finished tracing the shapes. It sometimes takes a couple of goes at drawing different shapes to see a rotation value applied.
(In reply to Regina Henschel from comment #8) > The rotation exists for straight lines. But it is not "arbitrary". It is the > angle of the line. The purpose it, that text in such line follows the line. ... but I do agree with you for a single line: it does make sense to have that rotation value for the text to follow its direction, its a useful feature and the value is unambiguous. But for the four shapes I listed, it is very ambiguous and in my opinion it would in most cases give a value that the user wasn't expecting.
Actually, I think I understand the behaviour a bit better now: the rotation is not arbitrary but it is defined by the first segment that was drawn for the shape. So to reproduce, you have to make sure that the first segment you draw is not a horizontal line going from let to right. I edited the summary to be more accurate.
Issue is inherited, same in OOo 3.3. Still present in recent 24.2 master build.