Description: Allow overlap option for Frame and Graphics styles should be disabled by default. It's on Wrap tab in Frame/Graphics style dialog. Steps to Reproduce: 1. Open a new Writer document 2. Insert a first image using the icon on the toolbar 3. Insert a second image using the same method at once 4. You don't see the first image that is covered the second image Try uncheck the Allow overlap option in on Wrap tab in Graphics style dialog and then try repeat steps 2-3. The images will be inserted as should be - second is below first. The option for Frame style should be disabled by default too because it gives the same ugly result when you try insert images with activated AutoCaption option Actual Results: We have overlapped images by default and should manually disabled the Allow overlap option before images inserting Expected Results: We have a good order for the images in the document by default and shouldn't do any additional actions Reproducible: Always User Profile Reset: No Additional Info: Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community Build ID: a8df5c815c8b002b7083b8777e3dd8beac573bf3 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded
*** Bug 149451 has been marked as a duplicate of this bug. ***
(In reply to Roman Kuznetsov from comment #0) > Description: > Allow overlap option for Frame and Graphics styles should be disabled by > default. > > It's on Wrap tab in Frame/Graphics style dialog. > > Steps to Reproduce: > 1. Open a new Writer document > 2. Insert a first image using the icon on the toolbar > 3. Insert a second image using the same method at once > 4. You don't see the first image that is covered the second image > > Try uncheck the Allow overlap option in on Wrap tab in Graphics style dialog > and then try repeat steps 2-3. The images will be inserted as should be - > second is below first. Step 3 is not giving the expected result. I have to deselect the first image and only then insert the second one. Otherwise the first image will be completely replaced by the second one no matter what the Allow overlap option is. Anyway, something for the design team.
(In reply to Buovjaga from comment #2) > Step 3 is not giving the expected result. I have to deselect the first image > and only then insert the second one. Otherwise the first image will be > completely replaced by the second one no matter what the Allow overlap > option is. I believe Roman's STR was done intentional and made him report "Frame and Graphic Style must not overlap". Adding one image onto another (while selected) could mean: a) source is replaced (the current scenario) b) source takes it into the area properties (happens in case of shapes) c) image is placed on top of the other (happens when deselected) Common solution is c) but using a slight offset so both images are shown. We could also block the function to insert an image.
a valid ask I would say.
(and I assume the behavior changed a bit after the change of default inserting of images changed.)
Valid request, possible solutions in comment 3.
Bug 105102 is probably a duplicate.. I added it as see also because the status is UNCONFIRMED here. It appears it should be set to NEW based on comment 6
*** Bug 142964 has been marked as a duplicate of this bug. ***
*** Bug 57599 has been marked as a duplicate of this bug. ***
*** Bug 144849 has been marked as a duplicate of this bug. ***
Regina notes in duplicate bug 57599 that the "allow overlap" checkbox first appeared in LO 6.4 thanks to vmiklos' work for bug 124600. I really like duplicate bug 142964's described use case - drag and drop. Definitely I would not expect the images to be stacked on top of each other in that case (and I agree with the general idea of avoiding image overlap as a default). bug 102011 might be useful parallel. That leads to sw/source/core/doc/DocumentStylePoolManager.cxx SwFormatWrapInfluenceOnObjPos aOverlap(; aOverlap.SetAllowOverlap(false); aSet.Put(aOverlap); I'm not noticing the concern that this might affect previous documents. In fact, when I import an existing document, the graphics style itself still defaults to "overlap" as before. Doing this has the side effect of also creating draw:wrap-influence-on-position="once-concurrent" since this one format-setting handles multiple properties. P.S. Even with that change, Drag and Drop still didn't produce non-overlapping images, even though each image now specifies no-overlap (at least the ones I was testing with). It kind-of worked if a single page was large enough to hold them all.
(In reply to Justin L from comment #11) > I'm not noticing the concern that this might affect previous documents. True for ODT (since [if used] the graphics and OLE styles are written to the file), but not true for DOCX. Of course DOCX doesn't define the Graphics style, so our changes will affect the interactive editing of non-LibreOffice documents. I expect that for "overlap" there isn't to big of a threat to existing documents. Overlap for inline (AS_CHAR) images is irrelevant, and DOCX likes to write <wp:anchor allowOverlap="1" ... It doesn't seem to apply the graphics style against imported images anyway. OLE however seems to be a different story... Before accepting https://gerrit.libreoffice.org/c/core/+/177509?usp=search it would be prudent to identify if/why OLE applies the graphics style, and more importantly to fix no-overlap to work over page boundaries.
(In reply to Justin L from comment #12) > it would be prudent to identify if/why OLE applies the graphics style, The difference is that DocumentContentOperationsManager::InsertGraphic can be passed a pFrameFormat, and only if none is provided is RES_POOLFRM_GRAPHIC accessed, while the two functions using RES_POOLFRM_OLE don't have an option to be passed a pFrameFormat, so they always apply RES_POOLFRM_OLE.