Created attachment 44188 [details]
With "LibreOffice 3.3.1 – WIN7 Home Premium (64bit) English UI [OOO330m19 (build 8 / tag 220.127.116.11)]" (and more early versions) it's hard to select elements. Although the complete little drawing is within the mouse selection frame, it will not be selected after you will have released the frame.
Steps to reproduce:
0. Open attached sample
1. <control>+<a> to check what the complete DRAWING might be. You will see
control points for the small 28x8 mm Drawing
2. <esc> to unselect
3. Try to select complete little drawing, for that create a selection frame
with the mouse pointer. Click app. x/y 20/30 and drag mouse pointer with
pushed left button to app. 70/60
A selection frame will be shown 20/30 - 70/60 that includes the complete
4. Release mouse button
expected: complete drawing within selection frame will be selected
actual: only circle with "Y" and small bar at the left to the rectangle
with the flaps will be selected, rectangle with flaps remains
You will have to span a really very big selection frame to get all Drawing selected, that makes it really difficult to select parts of a bigger drawing.
It seems that the problem is caused by rotation of parts of the drawing. If you click the rectangle, rotate (around center) clockwise 90°, click the 3 flap elements and also rotate (around center) clockwise 90°. Afterwards you can select that rectangle with contents or also including the Y-Circle without problems.
I can not remember to have seen that with OOo 3.1.1 (I will check soon), but I see the same problem with OOo 3.4-dev
Created attachment 44401 [details]
Drawing showing issue clearly
I can reproduce this issue in LibreOffice 3.3.1 OOO330m19 (Build:8) tag libreoffice-18.104.22.168 on Windows xp, as follows,
1. Open new drawing;
2. Draw a shape from Basic Shapes (eg. a rectangle);
3. Try to select the shape by covering it with a mouse selection frame. That will work;
4. Now rotate the shape by pressing right mouse -> Position and Size -> Rotation Angle -> Angle: 90 degrees;
5. Try to select the shape again by covering it with a mouse selection frame.
Expected: the shape can be selected with a frame slightly bigger than the shape.
Actual: the invisible bounding box appears to be extended somewhere south of the shape, so the shape cant be selected by a selection frame just around the shape.
Note that this bug doesnt occur with the Rectangle (the one not from the basic shapes).
I added a picture where the estimated extension of the bounding box of a rotated rectangle (from basic shapes) is marked with a dashed rectangle (you can find the bounding box by clicking on the shape and hovering over the paper; the cursor will change when it hovers over the bounding box).
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
I can confirm that this bug is reproducable in LibO 3.5 beta2. The bug is likely of the same source as one described in OpenOffice bug# 102496. A selection failure exists not only for shapes but also for very basic drawing element like a connector (LibO 3.5 beta2 also). This makes a work with Draw application very frustrating up to unusable.
This is my findings on selection failure for a connector.
1. Draw a connector line (for example, from lower left (start) to upper right (end).
2. Selecting the connector by clicking it in all its points or by selection area around it works perfectly.
3. Move upper end (end) down below its lower end (start).
4. Try to select it. Nope! You can't, except at the very proximity to the upper end (start). Selection by area is not working at all.
5. Select connector by clicking on the very upper end (start) and move that end a bit down. From now on you have no chance to select connector at all.
Even workaround exist, it in not in favour of Draw usability. You can use selection by area around old position of the connector to select it (if you still remember where it was originally).
Seems like some shape modifications (rotation, etc?) or movement of connector's ends fools selection data of the element.
I also show this bug in 3.5.0 on Windows. In addition to making selection with a mouse annoying, this bug causes problems when exporting a selection.
For example, attempt to export the network diagram attachment to a .PNG. Use CTRL+A to select the entire diagram, and note the location of the bounding box. Then use export and check the "selection" option. The resulting image will contain extraneous empty space.
Created attachment 58313 [details]
Network diagram example
*** Bug 46360 has been marked as a duplicate of this bug. ***
I also see problem with 3.3.0
I can also reproduce with LibO 22.214.171.124 on Linux. This makes me crazy, especially for files which contain several draws (because you cannot use Ctrl+A, else you would select all draws). This is a severe regression.
Is there a way to bring this bug to the attention of LibO developers for 3.5.3?
*** Bug 48281 has been marked as a duplicate of this bug. ***
*** Bug 51205 has been marked as a duplicate of this bug. ***
Bug doesnt't occur on self-drawn shapes
Hence I guess that the clipart shapes have a fine and a coarse bounding box, the latter of which is intended to speed up things and is calculated wrongly and is ignored when clicking the shapes directly.
Even if its converted from a clipart shape to a polygon shape, the error ceases to occur. However, at least what the double arrow, the moon, the rhomb and the stars are concerned, additional points do appear in the corners between shape and bounding box.
To bad we have no lasso tool.
I am also having the same problem, which makes it very frustrating to use LO Draw. I noticed that the problem happens when I rotate a shape.
Every time I have a shape rotated, I cannot select it... It seems that, in the background, LO keeps the original position and area of the shape. And when I export the image to PNG or JPEG, it includes a undesired blank space.
I cannot reproduce that- What Version? What OS? (What Processor?)
It would be interesting how it looks like-could you include such a jpeg file
(Best one where you can select the whole scope of the rectangle???)
Created attachment 63804 [details]
Description of how the problem occurs
Created attachment 63805 [details]
Original LO Draw file used to describe the problem
Created attachment 63806 [details]
PNG file generated after exporting the drawing
Lennard, I am using LibreOffice 126.96.36.199 (the latest version in repositories). My processor is an Intel i5 64bit and my OS is Ubuntu Linux 64.
I attached three files describing how the bug occurs. First is a PDF file describing the steps to reproduce the bug. The second file is the ODG file I created while writing the bug description. I also included the PNG file exported by LO with the blank spaces I mentioned.
Hope it'll help!
(In reply to comment #14)
> I cannot reproduce that- What Version? What OS? (What Processor?)
> It would be interesting how it looks like-could you include such a jpeg file
> (Best one where you can select the whole scope of the rectangle???)
Created attachment 64238 [details]
Artefact ABB35079 is moved by svdtrans
@Rafael Lima: Thanks a Lot.
Of course, I can reproduce it. I just understood it differently.
It ONLY occurs when you export a selection. Additional Bounding Box (lets call it ABB35079) is always to the right of the shape.
Obviously, there is some coordinate Information ADDED to the Shapes - Information that isn't rotated.
But it must be shifted during rotation. the additional bounding box seems always to be on one end of the Figure.
(the end that was the left one before the rotation)
I (initially) thought the bounding box was checked - in unrotated state - BEFORE the fine selection was done, just like a coarse check.
But as there is not such a coarse check amongst the selection it turns out that the respective bounding box seems to be additional geometry information INSIDE the shape.
If you mess up the positioning by defeating the rotating routine in /svx/..../svdtrans.cxx, the selection frame is shifted and the >>Additional Bounding Box<< ABB35079 is shifted with it, too!
(since now, the rotation selection is not rotated, it is identical now to the >>Additional Bounding Box<< i call ABB35079. So the ABB35079 must be something that is shifted by the svd rotating routine.
(While the VISIBLE Data Structure is rotated by something else).
(Where is the routine that defines the standard shapes?) I guess i'll find out...
What is the difference between userdrawn/=converted curves and standard shapes?
Where is the routine that rotates the shapes?
I found out that if you
drawinglayer/source/primitive2d/baseprimitive2d.cxx # Line Nr about 127 in my git
basegfx::B2DRange getB2DRangeFromPrimitive2DReference(const Primitive2DReference& rCandidate, const geometry::ViewInformation2D& aViewInformation)
in a way that after
You add the further condition
if ((dynamic_cast< BasePrimitive2D*>(rCandidate.get()))->getPrimitive2DID()!=45) // Excludes auxiliary selection shape which is wrongly rotated
the Problem ceases to exist.
Should I submit this now, or should I first watch what adverse effects this brings with itself?
If you are uncertain you should discuss your patch on <email@example.com>
Fixing this bug this way causes the program to crash when exporting jpeg's
better use 61 ,,PRIMITIVE2D_ID_HIDDENGEOMETRYPRIMITIVE2D'' instead of 45.
I guess I can release this patch now.
Sorry for not writing PRIMITIVE2D_ID_HIDDENGEOMETRYPRIMITIVE2D instead of 61. but the pusher fixed it.
Patch submitted under MPL/LGPLv3.
Setting the Status to fixed
The bugfix had bad side-effects. breaking slide transitions. Perhaps i descended too much into the inner guts of the program.
OK, this should do it. Thorsten said I sould make a new id for that frame object, but since the current principle is that any ID belongs to a class and that would be extreme code duplication and sister classes also got flags, I add a flag that tells if it is a hiddengeometry from a customshape or from something different.
Besides, I would have to find and change any piece where the hiddengeometry is REALLY used.
But now, I really carefully check whether I broke something.
Obviously, the ,,invisible outline for the cases where no visible content exists''
was the problem, as it didn't work with the way custom shapes are rotated.
I deleted it. It seemed to bring no problems with exported files. (checked with MS Office Professional 2012)
Somehow, i didn't see the comment what the object was for before I submitted it. - ????