Created attachment 44188 [details] Sample document With "LibreOffice 3.3.1 – WIN7 Home Premium (64bit) English UI [OOO330m19 (build 8 / tag 3.3.1.2)]" (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 Drawing 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 unselected 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-3.3.1.2 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: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Hi 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. ***
<http://wiki.documentfoundation.org/BugReport_Details#Version> I also see problem with 3.3.0
I can also reproduce with LibO 3.5.2.2 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 3.5.5.2 (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! Thanks (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). (See picture). My Questions: (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?
Solved! I found out that if you Change in drawinglayer/source/primitive2d/baseprimitive2d.cxx # Line Nr about 127 in my git Function basegfx::B2DRange getB2DRangeFromPrimitive2DReference(const Primitive2DReference& rCandidate, const geometry::ViewInformation2D& aViewInformation) in a way that after if(rCandidate.is()) { 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?
Lennard Wasserthal: If you are uncertain you should discuss your patch on <libreoffice@lists.freedesktop.org>
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. http://cgit.freedesktop.org/libreoffice/core/commit/?id=234738874f29ed23cd2aafb470511b5acf411e3c 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. - ????