Description: Anchor to character movement through document different between object type Steps to Reproduce: 1. open the attached files 2. Click the image.. drag.. release.. an look at the position of the anchor Actual Results: The QR code behaves like 'to paragraph'.. always at the left border.. going up down.. based on paragraph.. if you drag to anchor to a position within the text.. it will anchor to all sorts of position for 5/6 times and goes back to 'left/paragraph anchoring' The cat image anchor goes all over the place by default Expected Results: Anchor to character should behave the same for all 'objects'.. Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 7.1.0.0.alpha0+ (x64) Build ID: a201ab6f47c2d5a7ba4c5f998b0aa231cae82010 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL and in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
@Michael I'm not able to assess this; I only observe anchoring to character behaving differently depending on object.. I don't see the point, except legacy and likely backwards comp-ability.. But looks hard to maintain (ok, not touched that often). But not really helpful for solving anchoring/wrap issues in some future version, IMHO
i don't see a reason why the moving behavior should be different for different object types, possibly there are different code paths for different object types but any difference is likely a historical accident.
Created attachment 162007 [details] Example A (assuming to be wrong)
Created attachment 162008 [details] Example B (assuming to be proper)
Behavior of 'to character' Group A Unpredictable; messy anchoring (also affected by wrap) - Image - Chart - Gallery Items - Frame - Caption frame - OlE - Formula Group B -> Pretty straight forward behavior – Shapes – QR code – Font work – Form controls – Audio/Video object Look like a 'to paragraph' as reference; with the ability to pick something else.. moving a shape a lot a round.. and it will opt for 'to paragraph' handling (until the anchor is moved to specific character). However, no clue what will happen if Group A starts acting like Group B. It could improve the situation (to types of 'to character 'anchoring can compete today), or the result would be some bunch of wrap/anchoring/page loop issues.... I start remembering something a bad paragraph splitting across pages related to shape anchoring.. (anchor page 1/ shape page 2). The Group A anchoring is rather flexible in that area.. it's goes all over the place, so object/anchor mismatches is nearly never ever an issue.. The anchor is nearby the object nearly all the time. It is possible, to have anchor at some distance of the object, but you have to make the anchor (to character) do things it doesn't want to do. Not sure if a 'simulation' can be done by running it through Jenskins, Junit tests.. and maybe Xisco his LibreOffice/Word compare test.. To only see what could be expected. I personally prefer uniform behavior for a anchor (from user perspective/as development).. but OTOH text/page flow is quite a thing...
Created attachment 162100 [details] Image to paragraph
Created attachment 162102 [details] Image to character
Created attachment 162103 [details] Shape to paragraph
Created attachment 162104 [details] Shape to character
FWIW: the anchoring is one big mess (surprise). Two variants of "To paragraph" & "To Character" Image "To paragraph' is quite 'safe' (some flaws, but OK) Image "To Character' more broken layout (empty pages) etc. Has flaws on insertion.. but reasonable fine. Of course with the anchoring being unpredictable and such.. Shape "To paragraph" will freeze -> layout loop on a wrong move already in 3.3.0 Shape "To Character" will freeze -> layout loop on a wrong move already in 3.3.0 So maybe the other way around.. replace the current shape anchoring with the image anchoring (and solve the remaining issues in that area)
Created attachment 162110 [details] Screencast Shape to paragraph freeze
@Miklos Is it possible this bug discussed at a ESC meeting.. Two variant of anchoring of "to character"/"to paragraph"depending on object type) isn't really helpful, IMHO Especially with one variant causing layout loops Another step would be to solve some of the remaining issues with image anchoring (to paragraph/to character).
Created attachment 162645 [details] Example file DOCX The whole anchoring thing is getting really confusing. A DOCX anchor to character does things differently compared to an ODT (except if the ODT is generated from DOCX).. The DOCX has something or is lacking something, which makes to anchoring doing things differently.. for some unobvious reason
Created attachment 162646 [details] Screencast DOCX example
(In reply to Telesto from comment #13) > Created attachment 162645 [details] > Example file DOCX > > The whole anchoring thing is getting really confusing. A DOCX anchor to > character does things differently compared to an ODT (except if the ODT is > generated from DOCX).. The DOCX has something or is lacking something, which > makes to anchoring doing things differently.. for some unobvious reason Another reason a assume something being different - Suffers from image behind text flaw (bug 134509 which appears to be specific for DOCX) - Far less cases where empty page appears.. when dragging images around.. not saying the results a great.. 5 lines a page.. etc.. but still.. no empty pages (yes, if you try hard.. but a lot less) However lacking the proper knowledge.. how everything is relate to each other and/or being (dis)contected. However having a multitude of different behaviors with doesn't make tracking bugs easier (ODT from DOCX is not plain ODT).. solving them neither (as appears the same stuff has to repaired multiple times over the place).. And I don't think this any better from user perspective.. a doc doing all sorts of bizarre things..
(In reply to Michael Stahl (CIB) from comment #2) > i don't see a reason why the moving behavior should be different for > different object types, possibly there are different code paths for > different object types but any difference is likely a historical accident. Michael, so you confirm this behaviour as a bug? I can't assess this. Report has keyword needsDevEv. What input is needed by developers?
needsDevEval is used for potential easy hacks. The one you were looking for is needsDevAdvice
Just an observation: When an image or frame anchored "to character" moves to another paragraph, the new anchor point consistently appears to be the character closest to the top-left corner of the image (or frame) at the time the mouse button is released. Of course, with text wrap, the text immediately re-arranges itself causing the anchor to appear to randomly located itself. For the QR code it appears to choose the paragraph start as the new anchor location. I prefer the latter because the alternative behaviour with the image and frame appears random, even though it's not. It also fits what the anchor is actually showing the user at the time of moving the object, which is indicating where the actual reference point is for the object. (For anyone who isn't familiar with this anchor option, the reference point for "to character" anchoring is always the start of the paragraph, not the anchor location. When moving the anchor itself to any point in a different paragraph, the object retains the same offset from the new paragraph start as it has from the previous paragraph start.) With this observation, it does seem as though there is a line or two of code difference between the "group A" and "Group B" objects when choosing the new anchor location.
(In reply to Buovjaga from comment #17) > needsDevEval is used for potential easy hacks. The one you were looking for > is needsDevAdvice Polite png to developers in cc (Miklos and Michael) : Could you give some advice?
I think the reply from comment 2 still stands. This is probably not intentional, if somebody comes up with a fix, it would be probably welcome.
(In reply to Miklos Vajna from comment #20) > I think the reply from comment 2 still stands. This is probably not > intentional, if somebody comes up with a fix, it would be probably welcome. Miklos, thank you for your answer. So I take this as developer advice and change status to NEW.