By default libreoffice inserts images as To Paragraph, Optimal and many users coming from other word processors are not familiar with LO's image insertion behaviour and may like to change this default behaviour. So i'd like to suggest that in Tools > Options > LibreOffice Writer > General, we add a section entitled 'Image Insert' and provide two drop down lists - 1) Anchor, 2) Text Wrap. Defaults in other word processors: MS Word - In Line (aka As Character) WPS Writer - In Line (aka As Character) Google Docs - In Line (aka As Character) WordPerfect - Paragraph, Square/Both Sides (aka Paragraph, Parallel) Abiword - In Line (aka As Character) Calligra Words - Floating Free (aka To Page, Optimal) Is there a reason why LO has decided to stick with this default anchor and wrapping preset for insertion of images?
Another setting worth providing options to is alignment, as presently, inserted images are always center aligned.
CCing iplaw and foss to add how iWork inserts an image.
Hi Jay Is MS Word - In Line _as_ character or _at_ character? Two suggestions to work on this idea: 1. could we advice something wrt exchange of files with other word processors? 2. I think this on is interesting to ask on users@. Will do for Dutch language. Cheers, Cor
Hey Cor (In reply to Cor Nouws from comment #3) > Is MS Word - In Line _as_ character or _at_ character? MS Word calls it 'In Line', LO calls it 'As Character'.
(In reply to Jay Philips from comment #0) > By default libreoffice inserts images as To Paragraph, Optimal and many > users coming from other word processors are not familiar with LO's image > insertion behaviour and may like to change this default behaviour. So i'd > like to suggest that in Tools > Options > LibreOffice Writer > General, we > add a section entitled 'Image Insert' and provide two drop down lists - 1) > Anchor, 2) Text Wrap. > > Defaults in other word processors: > > MS Word - In Line (aka As Character) > WPS Writer - In Line (aka As Character) > Google Docs - In Line (aka As Character) > WordPerfect - Paragraph, Square/Both Sides (aka Paragraph, Parallel) > Abiword - In Line (aka As Character) > Calligra Words - Floating Free (aka To Page, Optimal) > > Is there a reason why LO has decided to stick with this default anchor and > wrapping preset for insertion of images? I would also like to have such an option. Now, I always have to change from anchored To Paragraph to anchored As Character, because I normally need to have it anchored as character. Therefore, this behaviour is currently very inconvenient for me.
Looking at the video and images sent to me by Alex and Steve, images inserted in iWork Pages are set to automatic wrapping (similar to LO's parallel wrap, but smarter) with automatic contour and 12pt (0.42 cm) spacing and an anchor of 'To Character'. After seeing the spacing being applied in Pages, i went to check if MSO did the same and yes it does. MSO inserts an image with a default 0.13" (0.33 cm or 3.69 pt) spacing on the left and right, which is does not take effect when an image is anchored 'As Character' or wrapped as 'None'.
what popup up in my mind (sorry for that ;) ) to check for this issue: - what is the behaviour when a paragraph with an image crosses the page border, because of adding/deleting content above it? - is there a difference when exporting to doc(x)? - in one of the choices more stable in settings when moving the image in the document? Things like that. Of course this focus is wider then just: what do the others do, but has important aspects too for user experience.
(In reply to Cor Nouws from comment #7) > - what is the behaviour when a paragraph with an image crosses the page > border, because of adding/deleting content above it? Only when an image is anchored 'To Page' does it not move with the content it is attached to, as its position is fixed on that particular page. > - is there a difference when exporting to doc(x)? Doc(x) doesnt translate 1 to 1 between LO's anchor settings (bug 49179). Microsoft doesnt present users with both anchor and wrap options by default. They show a list of wrap options, all of which are anchored 'To Character' though it never shows the anchor in the interface, except for 'In Line' wrap which is anchored 'As Character'. > - is one of the choices more stable in settings when moving the image in the > document? Setting anchor to 'To Page', 'To Paragraph' and 'To Character', all act the same way when moving an image on a page, only that 'To Page', the image doesnt move along with text movement. > Of course this focus is wider then just: what do the others do, but has > important aspects too for user experience. MS Word, iWork and Google Docs use 'To Character' when they allow an image to be wrapped, but most dont show the anchor position indicator on the page.
(In reply to Jay Philips from comment #8) > > - is one of the choices more stable in settings when moving the image in the > > document? > > Setting anchor to 'To Page', 'To Paragraph' and 'To Character', all act the > same way when moving an image on a page, only that 'To Page', the image > doesnt move along with text movement. I didn't talk about a stable position. I meant when a paragraph moves with an image in that paragraph. When that crosses a page, at some moment... Does that differ with one or the other option..
(In reply to Cor Nouws from comment #9) > I didn't talk about a stable position. I meant when a paragraph moves with > an image in that paragraph. When that crosses a page, at some moment... > Does that differ with one or the other option.. When an image is anchored as 'To Paragraph', 'To Character', or 'As Character' and the movement from page to page is exactly the same with 'To Paragraph' and 'To Character', while 'As Character' acts different. With 'To Paragraph' and 'To Characer', an image can appear over the page's margin when its position not enough text from the paragraph has moved onto the previous or next page, while this doesnt happen with 'As Character'.
Kendy had suggested getting rid of anchor 'to character' and Matthias stated there were use cases for it and provided the following document as an example. https://drive.google.com/open?id=0B_FrHYxnQ3axR0pfUzQ2T05FcTg&authuser=0
On of the benefits of anchoring 'as character' is that when you add a caption for the image, the image stays in the frame, rather than being able to move outside of the frame's borders.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
wrt anchoring and wrapping: would it be an idea to conclude that after more investigation wrt interoperability? It's not per see sure that 'just' having the same default value as another application, makes interoperability better. Then we can keep this issue for that and use another for spacing..
From bug 102011: When wrapping text around an image, the text will touch or almost touch the image by default. To add whitespace one must: * Double click on the picture * Click on "borders" * Enable a border * Set line style to something, if it's on none * Set color to white (or your page background) * Now, the "spacing to contents" box unghosts. Check "syncronize" and dial all four numbers to zero. * Now uncheck "syncronize" and distance to the direction you need (e.g. left or right depending on where the image is place). This workaround has been good for many revisions of libreOffice. Could it be made easier? Having "spacing to contents" start out enabled would be a good start.
*** Bug 102011 has been marked as a duplicate of this bug. ***
(In reply to Cor Nouws from comment #14) > wrt anchoring and wrapping: would it be an idea to conclude that after more > investigation wrt interoperability? We dont have any interop issues with anchoring and wrapping, so not an issue for whatever default we choose. > It's not per see sure that 'just' having the same default value as another > application, makes interoperability better. The default setting is about choosing what is best for users and not about interop. > Then we can keep this issue for that and use another for spacing.. As it is wrap spacing, it falls under wrapping which isnt another issue. (In reply to Heiko Tietze from comment #15) > From bug 102011: > > When wrapping text around an image, the text will touch or almost touch the > image by default. To add whitespace one must: As stated in that bug, using border spacing isnt the way to achieve wrap spacing, as you would need to first enable borders to be able to then add border spacing.
Hé :) (In reply to Yousuf Philips (jay) from comment #17) > We dont have any interop issues with anchoring and wrapping, so not an issue > for whatever default we choose. The way in image is anchored by default, influences how it behaves when saved as Ms.doc(x). It might well be that the default setting has influence on import of documents (have seen that with another setting in the past.) > As it is wrap spacing, it falls under wrapping which isnt another issue. I mean wrapping and anchoring as it influences saving as doc(x) and work in other office suites.
(In reply to Cor Nouws from comment #18) > The way in image is anchored by default, influences how it behaves when > saved as Ms.doc(x). Not doubt it does. :D > It might well be that the default setting has influence on import of > documents (have seen that with another setting in the past.) Well that would be an import bug. :D > I mean wrapping and anchoring as it influences saving as doc(x) and work in > other office suites. That is an export issue and the focus here is about setting the best default for LO users.
FYI https://bugs.documentfoundation.org/buglist.cgi?cmdtype=dorem&list_id=632697&namedcmd=RDC_W_NotResolved_Frame_Image_Object&remaction=run
(In reply to Cor Nouws from comment #20) > FYI > https://bugs.documentfoundation.org/buglist. > cgi?cmdtype=dorem&list_id=632697&namedcmd=RDC_W_NotResolved_Frame_Image_Objec > t&remaction=run Got the message "The search named RDC_W_NotResolved_Frame_Image_Object does not exist."
(In reply to Yousuf Philips (jay) from comment #21) > Got the message "The search named RDC_W_NotResolved_Frame_Image_Object does > not exist." I tried to set it available in my prefs, but that went wrong somehow, Does it work now?
(In reply to Cor Nouws from comment #22) > I tried to set it available in my prefs, but that went wrong somehow, Does > it work now? Still no luck. :(
(In reply to Yousuf Philips (jay) from comment #23) > (In reply to Cor Nouws from comment #22) > > I tried to set it available in my prefs, but that went wrong somehow, Does > > it work now? > > Still no luck. :( OK :) https://bugs.documentfoundation.org/query.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cpriority%2Cbug_severity%2Cshort_desc%2Cchangeddate&component=filters%20and%20storage&component=Writer&f1=short_desc&f2=short_desc&keywords=doc%20docx&keywords_type=anywords&o1=anywordssubstr&o2=anywordssubstr&product=LibreOffice&query_format=advanced&resolution=---&v1=docx%20doc&v2=frame%20image%20object&known_name=RDC_W_NotResolved_Frame_Image_Object
@Cor: Not sure how a list of import and export ms doc bugs relates to this issue. This issue isnt about interop and it would be no different than a user setting what we choose as default and import/export with that. We can test to make sure interop with ms works as expected for whatever we decide is the default but that wouldnt be the priority of this issue.
(In reply to Yousuf Philips (jay) from comment #25) > @Cor: Not sure how a list of import and export ms doc bugs relates to this > issue. The way in image is anchored by default, influences how it behaves when saved as Ms.doc(x). It might well be that the default setting has influence on import of documents (have seen that with another setting in the past.) This issue therefore is inevitably related with interop.
Looking at bug 100748, it seems that when inserting an image into a table, its default should be to insert it as a character rather then to paragraph.
(In reply to Yousuf Philips (jay) from comment #27) > Looking at bug 100748, it seems that when inserting an image into a table, > its default should be to insert it as a character rather then to paragraph. From what I hear from MSOffice-users-experience, that should be the default in normal text too.
(In reply to Cor Nouws from comment #28) > From what I hear from MSOffice-users-experience, that should be the default > in normal text too. Well just because that is what MSO defaults to doesnt mean it is the best solution for users. The first question that we need to address here is whether users should be able to move an inserted image or not after inserting, because As Character doesnt allow this and the other anchor options do. If i look at my last few documents i created, 1) if i insert an image on a blank line, inserting it as As Character works fine, and then i center the image if it doesnt take up the complete width of the document. 2) if i insert an image in a paragraph, inserting it as To Paragraph works fine, as i normally then resize the image if needed and then right align the image with the margin.
*** Bug 104320 has been marked as a duplicate of this bug. ***
Another drawback of anchoring images "To paragraph" by default is that this makes them harder to select by keyboard users. In other words, this issue is also an accessibility issue. The Accessible Digital Office Document (ADOD) Project recommends anchoring images "As Character" : https://adod.idrc.ocadu.ca/oowriter#tech4
*** Bug 127220 has been marked as a duplicate of this bug. ***
I've come across this old discussion (with recent additions) because it seems in 6.4 beta insertion has been changed to "As Character" when before it was to paragraph. But there doesn't seem to be a default in the Graphics style to alter this anchoring default back to paragraph. Naturally I would like to be able to chose, and the old To Paragraph worked well for me where I had to overlap small inset images over other images, whereas this new As Character is a pain as I'm now having to be altering many images I'm putting in which I didn't have to do before. In terms of working procedure, a person might want to choose one default and set in all the pictures in place (eg into Table cells) and then switch to a different default in order to do many insets over them etc. d Version: 6.4.0.0.beta1 (x64) Build ID: 4d7e5b0c40ed843384704eca3ce21981d4e98920 CPU threads: 2; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-GB Calc: threaded
...looking a bit more closely it wouldn't be so bad if a 'Wrap Through' item could be successfully placed as an inset over an As Character picture (other wraps seem to push the picture away), but if you do so you then you can't select it afterward to adjust it by clicking on it. Sometimes you manage to use the pointer select tool to catch it in a rectangle if it happens to be in the right position, but one I'm looking at I can't even do that as it selects the As Character picture it's lying over. If I want to select the inset picture that's over it I have to change the As Character one under it to To Paragraph, do adjustments (which might simply be a case of wanting to move its position) and change back again the Character As picture, which is all crazy... z-indexes don't help. d
(In reply to DM from comment #33) > ...6.4 beta insertion has been changed to "As Character" when before > it was to paragraph. Surprising since UX discussed the topic around the (still open) bug 45778 in https://wiki.documentfoundation.org/Design/Meetings/2019-05-15 with the suggestion to have an option.
(In reply to DM from comment #33) > I've come across this old discussion (with recent additions) because it > seems in 6.4 beta insertion has been changed to "As Character" when before > it was to paragraph. Good catch, this has actually been set to "To Character" on master since, because of the very annoying bug 87719. The commit should be backported to 6.4, because it was introduced after branching 6.4. The relevant commits are: - changing from "To Paragraph" to "As Character" https://cgit.freedesktop.org/libreoffice/core/commit/?id=4f40bf6a79de6d60da0a5090cdfeda6242e889f0 - changing from "As Character" to "To Character" https://cgit.freedesktop.org/libreoffice/core/commit/?id=a7528cd6f17ea5c5b29e7d607e54c62de0d9e7db (In reply to Heiko Tietze from comment #35) > Surprising since UX discussed the topic around the (still open) bug 45778 in > https://wiki.documentfoundation.org/Design/Meetings/2019-05-15 with the > suggestion to have an option. I'd imagine the reason for that is that changing the default equals to flicking a switch, while introducing an option for it is more work.
(In reply to Aron Budea from comment #36) > Good catch, this has actually been set to "To Character" on master since, > because of the very annoying bug 87719. The commit should be backported to > 6.4, because it was introduced after branching 6.4. And now it is: https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-6-4&id=d0aa2dbdf37aefe5b8d096fc5ea50cd13f87c5b0
Image is pasted with default anchor "To character" It is better default choice the anchor "As character" because the behaviour that a new user waits. My LibreOffice: Versión: 6.4.1.2 (x64) Id. de compilación: 4d224e95b98b138af42a64d84056446d09082932 Subprocs. CPU: 2; SO: Windows 6.1 Service Pack 1 Build 7601; Repres. IU: predet.; VCL: win; Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: threaded Thanks.
The bug was first reported in 2003 (did not see earlier one at least), so probably the best time to fix it would be 2023, or maybe 2053, if not 2103... Just take your time guys, only thousands of people want it.
Importance high due to number on CC and SeeAlso.
This issue is fixed since https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-6-4&id=d0aa2dbdf37aefe5b8d096fc5ea50cd13f87c5b0 @Heiko, or I missing something ?
(In reply to Xisco Faulí from comment #41) > @Heiko, or I missing something ? Wrapping and spacing has not been changed. Based on the patch it could be an easyhack, I guess.
Summarizing, we have in v7 (actually since 6.4) new defaults: * Anchor: To Character (drawback: no means to drag, see bug 87719) remaining defaults: * Position: Horizontal=Center, Vertical=Top (relevant at bug 87742) * Wrap: Optimal * Spacing: 0 (bug 102011) * Borders: 0 Still in discussion is: * comment 33: Choose default per tools > options + rather keep the last selection, see bug 109265 and comment 35 So we can resolve as fixed and open another ticket with the RFE to store last used option (could be done at bug 99646). Or just keep this ticket until it's done (and make 99646 a duplicate). Or reject this RFE. Related tickets: * bug 82873: Default behavior of inserting an image in a list + resolve as WFM or introduce special styles) * bug 45778: [RFE] Insert image not in a new paragraph but in the current position or as character + make as duplicate to this ticket * bug 87742: When image anchor is set to 'As Character' it should set vertical align to top + same as bug 82873, WFM or styles
We discussed this topic in the design meeting with the outcome to resolve this ticket as fixed and continue the discussion on bug 99646. From the minutes: * Default insert image anchor, wrapping, and spacing + https://bugs.documentfoundation.org/show_bug.cgi?id=87720 + comment 43 summarizes the discussion + 1) tdf#87719: does not apply for _to_ character but _as_ (Cor) => resolve as WF / by design + 2) fix tdf#102011 (easyhack, some UI tests fail) and tdf#87742 (has been discussed before) + 3) store the last choice (and maybe other settings too) + is it really desirable to remember the last anchoring across documents and sessions, eg. user changes just one image (Cor) + tools > option > formatting aids is the alternative, bloats the options and is not so easy to find (Heiko) => do it as an explicit option + "hijack" tdf#99646 to and resolve this ticket as fixed => agreed + 4) solve tdf#82873 / tdf#82873 per style and make one a duplicate of the other
I didn't follow the discussion in depth.. so maybe missing something.. Is there are reason that following elements are still anchored to paragraph by default: Shapes Textboxes Form buttons Frames And to character Image Chart I would expect everything to behave the same..
(In reply to Telesto from comment #45) > I would expect everything to behave the same.. Why? Consistency is good but the purpose of a frame is different than images. Or in what scenario do you insert a shape To Character?
(In reply to Heiko Tietze from comment #46) > (In reply to Telesto from comment #45) > > I would expect everything to behave the same.. > > Why? Consistency is good but the purpose of a frame is different than > images. Or in what scenario do you insert a shape To Character? Please, explain. Surely shapes/textboxes/form element have a different purpose. I'm not denying that. However, i'm not seeing how the purpose is relevant for the anchoring.. What is the benefit anchoring these "to paragraph"? Or the other way around what's objection against 'anchoring to character"? I'm not aware of the major differences (LibO help doesn't explain it either) I do know there * was a reason to change anchoring for images.. Does the same logic also apply for Shapes/Frames/Text Boxes, Form elements? * there is an odd exception of charts.. being anchored as 'to character' as well. How is this different from a shape? * Not sure how often a user makes a change to the default anchoring. I tend to stick with it, except if it behaves unexpectedly. However if we gonna mix different anchoring with probably (I can't find it) difference in behavior depending on the object.. This can cause surprises concern the layout. There also text layout issues related to anchoring. Depending on the type of anchoring. * Other inconsistency's: frame containing image, has same anchor as image. Empty frame has a different anchor. Was there an argument about the other objects? I'm raising the question.. My starting point is always consistency/ coherence/ conformity. This was the case before switching 'to paragraph' to 'to anchor'
Created attachment 159933 [details] Example file (In reply to Heiko Tietze from comment #46) > (In reply to Telesto from comment #45) > > I would expect everything to behave the same.. > > Why? Consistency is good but the purpose of a frame is different than > images. Or in what scenario do you insert a shape To Character? 1. Open the attached file 2. Set the cursor on page 2 and the end of the page (after yellow marking) 3. Insert a chart (positioned below) 4. CTRL+Z 5. Set the cursor on page 2 and the end of the page (after yellow marking) 6. Insert -> Image -> positioned on top of the page with anchor on given position 6. CTRL+Z 7. Set the cursor on page 2 and the end of the page (after yellow marking) 8. Drag a textbox on the second page (moves to the first page) 9. CTRL+Z 10. Set the cursor on page 2 and the end of the page (after yellow marking) 11. Insert a fontwork 12. CTRL+Z 13. Set the cursor on page 2 and the end of the page (after yellow marking) 14. Insert an interactive frame 15. CTRL+Z (CTRL+Z) 16. Set the cursor on page 2 and the end of the page (after yellow marking) 17. Insert a shape 18. CTRL+Z 19. Set the cursor on page 2 and the end of the page (after yellow marking) 20. Insert -> Media -> Audio/video object 21. CTRL+Z 22. Set the cursor on page 2 and the end of the page (after yellow marking) 23. Insert Object -> Ole object 24. CTRL+Z 25. Set the cursor on page 2 and the end of the page (after yellow marking) 26. Form -> Label -> Draw it on the second page 27. CTRL+Z 28. Set the cursor on page 2 and the end of the page (after yellow marking) 28. Form -> Checkbox -> Draw it on the second page 29. CTRL+Z 30. Set the cursor on page 2 and the end of the page (after yellow marking) 31. Form -> Push Button -> Draw it on the second page The whole list shows the problem with 'as paragraph anchoring' next to 'to character'. At the same time you can see different behavior with the same anchoring set depending on the object in use... madding by itself. And why do the form elements have different anchoring between them?
Please file a new ticket if you found new issues. Help about anchoring is here https://help.libreoffice.org/6.4/en-US/text/swriter/guide/anchor_object.html?DbPAR=WRITER#bm_id3147828 (help is never discussing pro and cons of different settings) Reason for the change was a) to align with other programs and b) have a reasonable default for the majority.
I think it is too bad that the as-character change wasn't simply reverted instead of being "fixed" by changing to another setting that had no time left for testing. Anchoring issues have always abounded, so a change this significant will obviously have huge ramifications. I find it very funny that this change was meant to improve compatibility with MS formats, but when I saved as at-character anchored image to docx format, it round-trips as an at-paragraph anchor. It still isn't too late to revert for stable 6.4.7...
Hello all. I waited this feature for years, and it seems you say that it now works. But it seems it doesn't work for me. Tested with: Version: 6.4.7.2 (x86) Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded Version: 7.0.2.2 (x86) Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded All images are inserted as anchored "to paragraph". I can change an individual image to be anchored "as character", but the next image will be inserted "as paragraph". So it works the same way as years before. And I see no option to change it. This is true for both images pasted from other sources (e.g., a web browser) using Ctrl+V and for images inserted using Menu > Insert > Image.
... Well, I was fooled by the anchor icon and by the placement of the image in the middle of the line. In Microsoft Office Word, if image is inserted as character, you won't see the anchor image and image will be in the beginning of the line rather in its middle. Now I see that image is actually inserted as character. Sorry.
Well, sorry again, folks. Now I see that image is actually inserted TO character. In almost all other apps it is inserted AS character. I think that AS is a way better. * It is more convenient to switch from one app to another * It is more intuitive. * Such an image is harder to confuse with the one anchored to paragraph. * And you can place multiple images in a row.
(In reply to gmolleda from comment #38) > Image is pasted with default anchor "To character" > It is better default choice the anchor "As character" because the behaviour > that a new user waits. > > My LibreOffice: Versión: 6.4.1.2 (x64) > Id. de compilación: 4d224e95b98b138af42a64d84056446d09082932 > Subprocs. CPU: 2; SO: Windows 6.1 Service Pack 1 Build 7601; Repres. IU: > predet.; VCL: win; > Configuración regional: es-ES (es_ES); Idioma de IU: es-ES > Calc: threaded > > Thanks. Which "new users"? Users asked "as character" for about 10 years. And newcomers from e.g. modern versions of MSO will expect the same. This is just insulting.
(In reply to John from comment #53) > Well, sorry again, folks. Now I see that image is actually inserted TO > character. In almost all other apps it is inserted AS character. The default cannot be set to As Character until bug 87719 is resolved, that is the primary reason why it is set to To Character right now.
(In reply to Aron Budea from comment #55) > (In reply to John from comment #53) > > Well, sorry again, folks. Now I see that image is actually inserted TO > > character. In almost all other apps it is inserted AS character. > The default cannot be set to As Character until bug 87719 is resolved, that > is the primary reason why it is set to To Character right now. Hello, Aron. Thanks. This is a quote by Heiko Tietze from the link you gave: > We discussed the topic in the design meeting. The default anchoring is To Character, by design, and those objects can be moved around. Not being able to drag an object when placed _As_ character makes sense consequently. As there is no other use case we better resolve the ticket as WF. So it's not clear to me: 1. whether that bug is _really_ intended to be fixed someday (WF - won't fix?) 2. ... and whether the default image anchoring would be changed to "as character" _even if_ that bug will be fixed.
(In reply to John from comment #56) > 1. whether that bug is _really_ intended to be fixed someday (WF - won't > fix?) Sure, anything can be fixed provided someone is interested in the topic and puts the time and effort into it. > 2. ... and whether the default image anchoring would be changed to "as > character" _even if_ that bug will be fixed. This discussion should be resumed once there is a fix, there's not much to talk about until then.
(In reply to John from comment #56) > (In reply to Aron Budea from comment #55) > > (In reply to John from comment #53) > > > Well, sorry again, folks. Now I see that image is actually inserted TO > > > character. In almost all other apps it is inserted AS character. > > The default cannot be set to As Character until bug 87719 is resolved, that > > is the primary reason why it is set to To Character right now. > > Hello, Aron. Thanks. This is a quote by Heiko Tietze from the link you gave: > > > We discussed the topic in the design meeting. The default anchoring is To Character, by design, and those objects can be moved around. Not being able to drag an object when placed _As_ character makes sense consequently. As there is no other use case we better resolve the ticket as WF. > > So it's not clear to me: > > 1. whether that bug is _really_ intended to be fixed someday (WF - won't > fix?) > 2. ... and whether the default image anchoring would be changed to "as > character" _even if_ that bug will be fixed. I don't know if this is the wrong place to put this, but it really seems like the whole discussion is missing the point. It really doesn't matter what the default anchor behavior is. There is a really simple solution which I am pretty sure was proposed in the first comment: Just add an option (somewhere) that lets the user set what they want as the default. As far as I can tell, you have to do a bunch of editing of stylesheets and whatnot, so I have to ask why we can't just add this as an additional setting? Users who are used to Word are going to want the default to be "As Character" so it would definitely be nice if they could change the default without too much trouble. Sounds less of a bug and more of a feature request!
(In reply to Jonathan Kayne from comment #58) Just add an option (somewhere) that lets the user set what they want as the default. See bug 99646
As a casual user it took me ages from https://blog.documentfoundation.org/blog/2021/02/03/libreoffice-7-1-community/ to actually find where this change has actually been implemented. The only reference is from April 2020. So for others - Tools > Options > LibreOffice Writer > Formatting Aids > Anchor.
(In reply to andrew.james.heard from comment #60) > As a casual user it took me ages... You may enjoy the release notes, see https://wiki.documentfoundation.org/ReleaseNotes/7.1#General_improvements
Thank you so much for this link You saved me a lot of time! (In reply to Heiko Tietze from comment #61) > (In reply to andrew.james.heard from comment #60) > > As a casual user it took me ages... > > You may enjoy the release notes, see > https://wiki.documentfoundation.org/ReleaseNotes/7.1#General_improvements https://hum2d.com/
Created attachment 173713 [details] Screenshots how I followed the hint to set the default anchoring of pictures which does not work. I tried the hint from https://bugs.documentfoundation.org/show_bug.cgi?id=87720#c60 but it does not work, as can be seen in the attached document with screenshots of what I did and what I experienced. After the fact, I anchored the two pictures in this document at paragraphs, as I always do.
After browsing several bug reports I am still not sure if this is the right place to post. Please point me to the right place if not. When inserting images, I expect that modifying the Frame style "Graphics" would change the defaults of the inserted image. That is true only to a certain degree. Settings for size are just ignored while settings for anchor is respected only when the anchor is Page. Expected behavior is that changing properties for the Graphics Frame style would have full impact when inserting images. Version: 7.2.0.2 / LibreOffice Community Build ID: 614be4f5c67816389257027dc5e56c801a547089 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: nb-NO (en_US.UTF-8); UI: en-US Calc: threaded Operating System: Kubuntu 20.04 with Ubuntu Studio KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kernel Version: 5.4.0-81-lowlatency OS Type: 64-bit Steps to reproduce: 0. Create a new document 1. Styles > Manage Styles > Frame Styles > Graphics 2. Modify settings and close 3. Insert > Image Modified settings example 1: Width: 9 cm (Height automatically changes to the same value) Keep ratio Anchor: To page Position: Center / Top to entire page Inserted image will have these properties: Width: 17 cm (same as text area on the page) Height: 22,67 cm Keep ratio Anchor: To page Position: Center / Top to entire page Modified settings example 2: Width: 9 cm / Autosize off Height: 9 cm / Autosize on Keep ratio Anchor: To paragraph Position: Center to paragraph area / Top to Paragraph text area Inserted image will have these properties: Width: 17 cm (same as text area on the page) Height: 22,67 cm Keep ratio Anchor: To character Position: Center / Top to page text area
(In reply to al F from comment #64) > After browsing several bug reports I am still not sure if this is the right > place to post. Please point me to the right place if not. Adding notes to fixed tickets is flogging a dead horse. If you think you found a bug (quickly reading over the text it seems so) please file a new ticket.
(In reply to Heiko Tietze from comment #65) > (In reply to al F from comment #64) > > After browsing several bug reports I am still not sure if this is the right > > place to post. Please point me to the right place if not. > > Adding notes to fixed tickets is flogging a dead horse. If you think you > found a bug (quickly reading over the text it seems so) please file a new > ticket. The ticket is marked as resolved, but the problem is not really resolved. 1. Would it not be possible, to re-open the old ticket: Then every one would see that it is an very old story. BTW: my last posting also showed that this is still an etching inflammation... If I would file a new ticket and alF would file another one, things might run apart again. 2. From a centralized standpoint (if you prefer to keep closed tickets closed): Would it not be better in such a case to "promote" such "late reopen"-cases as new cases, automatically providing links to old duplicates or quasi-duplicates? Just at the moment I refrain from filing a new ticket for https://bugs.documentfoundation.org/show_bug.cgi?id=87720#c63 because there is a risk that simultaneously a duplicate from alF is posted. I just try to reopen this old ticket instead.
(In reply to Adalbert Hanßen from comment #66) It's not the wisest idea to reopen a bug report just after someone being asked not to do that for old bug reports that have been closed for a while. Either of you can open a new bug report, add this to See Also, if you want you can even comment here and mention the new bug report. Following up on an old bug means having to read through dozens of comments, most of them not being relevant to the current situation. When you create a new one, you can have a clear description of the situation and what your problem is, and also take the existing feedback into account. Please do that.