Often I scan images, put it into document and put on raster images some arrows, other shapes, text. But while further edition image moves in one side and text and arrows in oter. I can not prevent it by grouping because I can not select nor images nor frames for grouping. I propose new ability: Grouping raster images with others graphics Grouping frames with others graphics In context menu for raster image add option to convert it to rectangle of same size with no borders and with raster image as texture (option Tile set off and option Autofit set on)
I think you cannot even group together two raster images. For example if I start with a blank Writer document, then insert two jpg images via Drag&Drop from the Desktop, I cannot (via means of holding Shift/Ctrl/Alt/something else and clicking) select them both so I can move them both at the same time. As I cannot select multiple images obviously I cannot group them. Is this the issue/missing feature you are talking about?
Yes
[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
remains in LibO 3.5.0 beta 1
*** Bug 45787 has been marked as a duplicate of this bug. ***
*** Bug 47056 has been marked as a duplicate of this bug. ***
*** Bug 50644 has been marked as a duplicate of this bug. ***
*** Bug 68733 has been marked as a duplicate of this bug. ***
I just want to say we are a SMB (60+ employees) this this issue is a deal breaker for migrating.
+1 I needed this feature today the first time, and i can not believe its not implemented... I changed the importance to high...
(In reply to Michael Nagel from comment #1) > I think you cannot even group together two raster images. For example if I > start with a blank Writer document, then insert two jpg images via Drag&Drop > from the Desktop, I cannot (via means of holding Shift/Ctrl/Alt/something > else and clicking) select them both so I can move them both at the same time. > As I cannot select multiple images obviously I cannot group them. > > Is this the issue/missing feature you are talking about? This problem is also confirmed in LibreOffice Writer 4.4.1.2 (Linux version).
Bug exists in LibreOffice 5.0 (Ubuntu 12.04.5 with PPA, 1:5.0.0~rc5-0ubuntu1~precise1).
Bug exists in LibreOffice 5.0.1.2 (Ubuntu 12.04.5 with PPA, 1:5.0.1~rc2-0ubuntu1~precise1.1).
*** Bug 101893 has been marked as a duplicate of this bug. ***
Bug is not fixed. Still unable to group images. Version: 5.1.6.2 Build ID: 1:5.1.6~rc2-0ubuntu1~xenial1 CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group
*** Bug 96129 has been marked as a duplicate of this bug. ***
*** Bug 49625 has been marked as a duplicate of this bug. ***
*** Bug 34442 has been marked as a duplicate of this bug. ***
Shift + Click does not work for selecting an image (or picture or bitmap) together with shapes or other images, because an image in Writer is no drawing object. So you can not make multiple selection with images. [Added some more description to make it easier in search to find this bug.]
Confirmed in following version and config: Version: 5.2.5.1 Build ID: 1:5.2.5~rc1-0ubuntu1~trusty0 CPU Threads: 2; OS Version: Linux 3.13; UI Render: default; VCL: gtk2; Locale: en-GB (en_GB.UTF-8); Calc: group
Created attachment 132703 [details] odt for testing multiselect Document for testing this bug: - try dragging a select box around all three elements; or - try adding the picture and a shape to the same selection by using the shift+click combination.
Bug exists in Version: 5.4.1.2 Build ID: 1:5.4.1~rc2-0ubuntu0.16.04.1~lo0 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group Ubuntu 16.04 LTS with PPA.
+1 for fix
*** Bug 113461 has been marked as a duplicate of this bug. ***
Still present in 5.2.7.2, +1 for fix. It really annoying convincing people to give LO a try when facing 6-years old, basic feature requests...
*** Bug 113698 has been marked as a duplicate of this bug. ***
*** Bug 114214 has been marked as a duplicate of this bug. ***
Reproduced Still exists in version Version: 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US Calc: threaded
*** Bug 121950 has been marked as a duplicate of this bug. ***
Do you wait until this bug can legally buy a beer?! It is already 8 years old...
(In reply to Marcin from comment #30) > Do you wait until this bug can legally buy a beer?! It is already 8 years > old... ++ :) 6.1.5.2 still reproduces
For the sake of completeness: confirmed in LO 6.2 with original attachment. Details: Version: 6.2.2.2 Build ID: 1:6.2.2-0ubuntu0.18.04.1~lo1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
*** Bug 126740 has been marked as a duplicate of this bug. ***
I have a suggestion: allow anything to be selected together, and grey-out or altogether remove possible right-click actions based on what those elements have in common. But basic movement of images in sync with other elements of a document is absolute base-level functionality, and should be replicated across the board.
Is there any update on this? I can't believe this has not been a priority since the beginning, I'd say it was pretty essential to creating documents. A simple CTRL + click to select multiple objects and then group them has been in MS Office since donkeys years.
Agreed, what makes it worse is that the keyboard expansion modifiers for raster images and other page elements appear to be reversed. I forget which way round it is, but using the keyboard button to modify the resize so that it's proportional expansion on one, cause the expansion to be non-proportional on the other. From a novice end-user POV this is insane behaviour.
Still the case in 6.4: Version: 6.4.0.0.alpha1 Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded
I will take this issue. See comment on bug 37960 comment 64.
I noticed that selection by Ctr+A also doesn't work in test document. There some be exclusive mechanism. Also, this problem is not reproduced on Draw, Impress, etc. sw module should have something about this issue?
(In reply to Yasunori Endo from comment #39) > I noticed that selection by Ctr+A also doesn't work in test document. It only works, if you add a new paragraph. But that's also the behaviour in other documents (don't know if this bug has been reported yet). Another question Yasnouri: You've assigned the bug to yourself. So that means you're going to fix it?
Still present in Version: 7.0.0.0.alpha1+ (x64) Build ID: 99c337d1d3831ce9d2c7dc1cbff713f4ac49d6ac CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: en-GB (de_DE); UI: en-GB Calc: CL
> Another question Yasnouri: You've assigned the bug to yourself. So that means you're going to fix it? Yes, I'm working on this issue.
(In reply to Yasunori Endo from comment #42) > Yes, I'm working on this issue. Great! Thanks a lot!
*** Bug 133885 has been marked as a duplicate of this bug. ***
*** Bug 139817 has been marked as a duplicate of this bug. ***
(In reply to Yasunori Endo from comment #42) > > Another question Yasnouri: You've assigned the bug to yourself. So that means you're going to fix it? > > Yes, I'm working on this issue. I guess we can reset Assignee. Anyone who is willing can take it again.
Code pointers: - All CLICK and SHIFT+CLICK operations for grouping Drawing objects handled in ./sw/source/uibase/docvw/edtwin.cxx:2770 : https://opengrok.libreoffice.org/xref/core/sw/source/uibase/docvw/edtwin.cxx?r=216a43bc#2770 - SHIFT+CLICK occurs in: https://opengrok.libreoffice.org/xref/core/sw/source/uibase/docvw/edtwin.cxx?r=216a43bc#3470 - Select objects : SwFEShell::SelectObj: https://opengrok.libreoffice.org/xref/core/sw/source/core/frmedt/feshview.cxx?r=715797bc#177 - Marked object list: https://opengrok.libreoffice.org/xref/core/include/svx/svdmark.hxx?r=40595834#230 - Types of forms of content: https://opengrok.libreoffice.org/xref/core/sw/inc/editsh.hxx?r=1feb59c3#130 - Mark object: https://opengrok.libreoffice.org/xref/core/svx/source/svdraw/svdmrkv.cxx?r=8a850eed#1877 You can read the full-detailed blog post of my 2-week research on this bug: https://bayramcicek.com.tr/libreoffice-dev/2021/07/05/week-03-04-gsoc.html (I don't want to write everything in the blog post here because it's too long), just want to point out: All selected objects store in rMrkList list: const SdrMarkList &rMrkList = pDView->GetMarkedObjectList(); Output of SAL_DEBUG( rMrkList.GetMarkDescription() ); (in SwFEShell::SelectObj): For shapes: "shapes" For 2+ shapes: "2 shapes" For draw images: "Image with transparency" For text box: "Text Frame" For raster images: "[Drawing object]" (defined as #define STR_ObjNameSingulNONE) rMrkList.GetMarkCount(); always increases by 1 when selecting drawing objects via SHIFT+CLICK. But always gives 1 when selecting raster images because pOldSelFly = ::GetFlyFromMarked( &rMrkList, this ); always return an address and this causes rMrkList doesn’t add the second selected raster image to itself and do unmark it. (if we force rMrkList to add raster images to itself by removing the pDView->UnmarkAll() line, this time, debugging warns "warn: /*...*/ frame is not accessible." ) I don't understand why images handled different in Writer and Draw/Calc/Impress. IMHO, should we get rid of writer-images and convert them into drawing objects as like in the Draw? Otherwise, from my point of view, it seems a bit complicated to group raster images and raster&shapes. What do you think? Thanks.
(In reply to Bayram Çiçek from comment #47) > > I don't understand why images handled different in Writer and > Draw/Calc/Impress. > > IMHO, should we get rid of Writer-images and convert them into drawing > objects as like in the Draw? Otherwise, from my point of view, it seems a > bit complicated to group raster images and raster&shapes. What do you think? From ODF file format there is no difference. So from my point of view we should get rid of Writer-images. But that is a long way. You see the differences, if you look at the supported services. You can use the "Development Tools" to easily get an overview. From user point of view the main differences are: Writer-images allow a wrap, which is determined by a user defined polygon. You get the wrap polygon via context menu -> Wrap > Edit Contour. Writer-images have the feature "Image Map". You get the "Image Map" via menu Tools > Image Map. Draw-images have no UI in Writer to crop them (bug 107843). So to get rid of Writer-images it would be necessary to implement the services, which are provided by Writer-images for Draw-images too. Converting a Writer-image to a Draw-image for grouping will work. But I would never do this silently, because it means, that the features of the image will be changed. If an operation in Draw can only be done with a special kind of object, the user gets a warning, that the object will be converted, and an option to agree or cancel. Try command 'Distort' on a star-shape for example.
Why is this listed as a "papercut"? From Regina's analysis in Comment 48, the developer is going to have to be very careful to not break things worse than they fix. For a student developer new the codebase, this sounds like a standalone project itself.
(In reply to Luke from comment #49) > Why is this listed as a "papercut"? From Regina's analysis in Comment 48, > the developer is going to have to be very careful to not break things worse > than they fix. For a student developer new the codebase, this sounds like a > standalone project itself. Me to blame for being on the list. Only did suggestions on the 'papercut' without understanding of the complexity. Actually full change of Writer image handling was not something I did foresee. Change of image handling is not done at GSOC if I'm reading this correctly: https://bayramcicek.com.tr/libreoffice-dev/2021/07/11/week-05-gsoc.html "developer is going to have to be very careful to not break things." Totally true. Sidenote: I personally prefer that changes are pushed into fresh master branch from nearly spin-off point. Which I call the Justin L strategy. As changing Writer image handling will certainly break things, kind of convinced of that. Some bugs will be very noticeable, if something goes wrong (especially if it affects page layout/wrap). So long testing/ repairing period would really helpful.
Really outstanding, helpful stuff. RJ | https://alhambracustomcabinets.com/kitchen-cabinets
Using 64-bit Linux Mint Cinnamon 17.1 with 4.0.4-040004-generic kernel LibreOffice version: 5.0.0.0.beta1 Build ID: 0a16c3dda4150008d9be6f24cbd15ac198d116d3 Locale: et-EE (et_EE.UTF-8) http://www.iu-bloomington.com/ Writing long comments will scroll automatically the comment first row to screen and writing place at the end remains unvisible from screen. Same situation - activating comment window to improve already written comment firstly will mark bunch of text because it tries to scroll long comment first row to screen and therefore will automatically mark a lot of text. It means that if the long comment was scrolled to the https://www.webb-dev.co.uk/ end and then tries to edit that comment - it means to write something to the end of long comment then it will automatically scroll the first row at the same time when activating comment editing and therefore will mark all text because mouse left cursor is pressed down and this means also text marking due to automatic scrolling. https://waytowhatsnext.com/ Here is one exception - when inserting long comment in case there is one comment before (upwards) then there will be scroll bar until there will be finished first editing session. But when once click outside the comment and then again back to improve it - then this error starts again - first row will be scrolled to the screen and downside of comment goes out of the screen and is not http://www.acpirateradio.co.uk/ viewable and thus hard to edit. Workaround is to write comment in some external text editor and just copy to the appropriate place, usually in the end of long comment. Using 64-bit Linux Mint Cinnamon 17.1 with 4.0.4-040004-generic kernel LibreOffice version: 5.0.0.0.beta1 Build ID: 0a16c3dda4150008d9be6f24cbd15ac198d116d3 Locale: et-EE (et_EE.UTF-8) http://www.logoarts.co.uk/ Writing long comments will scroll automatically the comment first row to screen and writing place at the end remains unvisible from screen. Same situation - activating comment window to improve already written comment firstly will mark bunch of text because it tries to scroll long http://www.slipstone.co.uk/ comment first row to screen and therefore will automatically mark a lot of text. It means that if the long comment was scrolled to the end and then tries to edit that comment - it means to write something to the end of long comment then it will automatically scroll the first row at the same time when activating comment editing and therefore will http://embermanchester.uk/ mark all text because mouse left cursor is pressed down and this means also text marking due to automatic scrolling. Here is one exception - when inserting long comment in case there is one comment before (upwards) then there will be http://connstr.net/ scroll bar until there will be finished first editing session. But when once click outside the comment and then again back to improve it - then this error starts again - first row will be scrolled to the screen and downside of comment goes out of the screen and is not viewable and thus hard to edit. Workaround is to write comment in some external text editor and just copy to the appropriate place, usually in the end of long comment. http://joerg.li/ Using 64-bit Linux Mint Cinnamon 17.1 with 4.0.4-040004-generic kernel LibreOffice version: 5.0.0.0.beta1 Build ID: 0a16c3dda4150008d9be6f24cbd15ac198d116d3 Locale: et-EE (et_EE.UTF-8) Writing long comments will scroll automatically the comment first row to screen and writing place at the end remains unvisible from screen. http://www.jopspeech.com/ Same situation - activating comment window to improve already written comment firstly will mark bunch of text because it tries to scroll long comment first row to screen and therefore will automatically mark a lot of text. It means that if the long comment was scrolled to http://www.wearelondonmade.com/ the end and then tries to edit that comment - it means to write something to the end of long comment then it will automatically scroll the first row at the same time when activating comment editing and therefore will mark all text because mouse left cursor is pressed down and this means also text marking due to automatic scrolling. Here is one exception - when inserting long comment in case there is one comment before (upwards) then there will be http://www.compilatori.com/ scroll bar until there will be finished first editing session. But when once click outside the comment and then again back to improve it - then this error starts again - first row will be scrolled to the screen and downside of comment goes out of the screen and is not viewable and thus hard to edit. Workaround is to write comment in some external text editor and just copy to the appropriate place, usually in the end of long comment. http://www-look-4.com/