Description: When I insert an image and then add a caption, selecting the image and selecting the "Add Caption" option from the pop-up menu, it adds the caption correctly. However, if you later try to select both the image and the caption simultaneously (for example, to resize the image and resize the caption accordingly), it becomes almost impossible. Additionally, if you select only the image, the "Add Caption" menu option reappears (when a "Modify Caption" option should appear), and if you click on it, it adds a second caption. This behavior wasn't the case in previous versions (although it has been doing so for months). Steps to Reproduce: 1.Insert an image into a Write document. 2.Select the image, right-click, select add caption, add the caption you want, press Enter to save it, and click somewhere else in the document to deselect the "image + caption" group. 3.Try selecting the image and its caption at the same time, you'll see that it's very, very, very difficult. Actual Results: Only the image is selected, but not the caption. Expected Results: That both the image and the caption be selected, so that, for example, the overall size or position of the image could be changed, and that the caption would accompany these changes. Reproducible: Always User Profile Reset: No Additional Info: Select only the image (sometimes by clicking hard you can select both).
I can confirm the bug in Version: 25.2.4.3 (X86_64) / LibreOffice Community Build ID: 33e196637044ead23f5c3226cde09b47731f7e27 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (de_DE); UI: en-US Calc: threaded But I can not reproduce in Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 27943324726c52027b527ceb4fa7646c6f21ed17 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded
I can also reproduce it in Version: 25.2.5.2 (X86_64) / LibreOffice Community Build ID: 03d19516eb2e1dd5d4ccd751a0d6f35f35e08022 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (de_DE); UI: en-US Calc: threaded
Reproducible. Version: 25.2.5.2 (X86_64) / LibreOffice Community Build ID: 03d19516eb2e1dd5d4ccd751a0d6f35f35e08022 CPU threads: 2; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: default
There is whole list of 'issues' with the caption frame, IMHO * I wouldn't expect the need to select the frame & the image to resize. Changing the frame size should resize the embedded object within (by default). This works in some cases, but not all the time * Also the context menu 'caption' for image within a caption frame is not ideal. * Being able drag the image outside the frame doesn't seem ideal either * Being able to change anchor of the image in frame also obscure (and undesired) * Modifying the caption label feels also bit unnatural to me. You can't directly access the label, you need to enter the frame But well it's inherent to the current implementation. There is no dedicated 'Caption Frame object', which I would expect. It feels bit like a quick and dirty implementation: simply a dialog automating the combination of separate build blocks. So something which could have been constructed manually by combining frame + image + field (numbering). A cobbled-together solution. It does the job in baseline, but if you start fiddling with the combined object, everything falls apart rather quickly It's apparently 'good enough' for quite number of users.
There is no such thing like image-with-caption that you can move around and manipulate together. And Writer cannot group objects like Draw/Impress. There is an object (the image) that has associated text (the caption) which should be placed together (done per frame). Flexibility comes with costs and might be understood as quick and dirty implemented. To clarify the situation: You should see a frame around image and caption; if not, please enabled View > Boundaries. My take: NOT A BUG. Do you agree, Miguel?
(In reply to Heiko Tietze from comment #5) >Flexibility comes with costs and might be understood as quick and dirty >implemented. I'm still curious what the concrete 'flexibility' advantages are. I don't see true benefits for the end-user. Simple tasks become more of a hassle (like resizing/ copy pasting). Making it worse: it's a commonly used feature. Sure the matter is convoluted. Some issues qualify as bugs today. So could/should be solved regardless of a dedicated caption + frame. Other really bound by current design, as far I can tell. A dedicated caption frame could surely give a more 'polished'/smooth/ fool proof experience. But well, I admit, the number of bugs reports is not overwhelming either.
(In reply to Telesto from comment #6) > I'm still curious what the concrete 'flexibility' advantages are. Caption at bottom/top, left/right, with margin/spacing, two images with one caption, etc. We can of course restrict the flexibility and simulate a special "captioned object". I bet more users complain then about some missing functionality (for sure edge use cases) than today about missing ease of use. I would rather think about grouping as requested in bug 34438 (and others) or to make the content of the frame, meaning image and caption, protected by default (look for this option under Properties > Position and Size).
(In reply to Heiko Tietze from comment #7) > (In reply to Telesto from comment #6) > > I'm still curious what the concrete 'flexibility' advantages are. > Caption at bottom/top, left/right, with margin/spacing, two images with one > caption, etc. We can of course restrict the flexibility and simulate a > special "captioned object". I bet more users complain then about some > missing functionality (for sure edge use cases) than today about missing > ease of use. > > I would rather think about grouping as requested in bug 34438 (and others) > or to make the content of the frame, meaning image and caption, protected by > default (look for this option under Properties > Position and Size). Well that could indeed work:-). Although, depends on the implementation. Like: can you still use Compress Image? Or copy the image without frame (instead of having to disable protection -> copy image -> Enable protection)
(In reply to Telesto from comment #8) > Well that could indeed work:-). Although, depends on the implementation. > Like: can you still use Compress Image? Or copy the image without frame > (instead of having to disable protection -> copy image -> Enable protection) That's flexibility you explicitly opt out ;-). But you can always uncheck the protection, modify the content, and activate again. My point is: Are the on board means sufficient, and if so, do we need to change defaults?