(In reply to Telesto from comment #0)
> And so on and so on.. not going to write down all objects and settings..
> Point is, Benjamin gets a headache of all those different positional
> settings.

And QA gets migraine on tickets without a clear issue :-)

We definitely cannot reduce the amount of use cases that condense in a complexity of the UI. And it's wrong to lump all objects together: while we went with To Character for images it makes not much sense for floating objects that are typically placed in front or behind some other. And the fontwork is such an object.

Happy to bring more consistency into the program but this ticket is too generic.

(In reply to Heiko Tietze from comment #2)
> (In reply to Telesto from comment #0)
> > And so on and so on.. not going to write down all objects and settings..
> > Point is, Benjamin gets a headache of all those different positional
> > settings.
> 
> And QA gets migraine on tickets without a clear issue :-)
> 
> We definitely cannot reduce the amount of use cases that condense in a
> complexity of the UI. And it's wrong to lump all objects together: while we
> went with To Character for images it makes not much sense for floating
> objects that are typically placed in front or behind some other. And the
> fontwork is such an object.
> 
> Happy to bring more consistency into the program but this ticket is too
> generic.

If you stick with the description yes, didn't write down much..  The STR is report is rather specific. Or do I really need to add 20 bug reports for every object separately ...

This is not about: Anchoring (floating); Not about wrapping, but about the position and size settings when inserting an object

Fontwork: Position is defined on insertion
Horizontal From left Paragraph *text* area. 
Vertical from Top Paragraph *text* area.

Textbox 
Position is defined on insertion
Horizontal From left to paragraph area. 
Vertical From top Margin (expected)

Image
Position is defined on insertion
Horizontal: Center + paragraph area. 
Vertical: Top & Margin

Why needs an image.. be inserted centered on Top..
And is the position of a textbox added on From left to paragraph area. From top Margin

This is not 'about' direct direct issue, but about something better not set this way. With a multitude of different positional settings for objects without having a clear functional advantage. I prefer a document with limited positional settings of objects, instead of all sorts of vertical/horizontal positional settings as a default

The answer to my issue should be quite easy... Ever settings on insertion (wrap/anchoring/positional horizontal/vertical) is documented by UX for all objects. Because it all are design decisions.. And all defaults are documented in a specification manual (for UX and DEV) with a clear line of argumentation. Even if they are made in StarOffice times.. And the logic is reconsidered every (say five? years). The world changes..

So my issue can easily answer.. (a) list all the default settings for each and every object (b) with an explanation why it chosen (And there is no effort in it, reference to a documentation; not split over years in a multitude of UX-sessions.. but the documentation for the current state). And the rationale why image pasted from Impress is different from one inserted in Writer (no there isn't, legacy story). And all those issues are documented and on the radar of UX as well; Everything would be explainable, even if long standing members with lots of knowledge would disappear (Note: I'm not considering myself as a long standing member, so i'm missing out on a lot of things)

So is there an actual issue with a specific object/insertion. No. The issue is at a higher level.. Why use some many different settings, if you can keep simpler by default (and less prone to errors). There are already quite a number of crashes related to type anchoring type. No crash with paragraph a crash with to character.. Or visa versa. File saved with to character opening with to paragraph anchor.. 
5 anchors.. 6 wraps settings (multiple with contours enabled). And object/position settings horizontal 4 (Left/ Right/ Center/From left) and 8 (area definitions). Again the same for vertical. Not even considering rotation & crop

So the number of possibility's add up

-- 
My bug reports surely not perfect. However there is sometimes some unwillingness to read between the lines. There is also some kind of double standard. I have to write a detailed report.. while people 'in charge' can go with a simple yes/no. Without even proper explanation for the current state..

Yes, you can state current setting works; there is no issue. However, something similar can be said for every dialog. Or you should stop redesign dialogs, as to old ones function (and new ones can cause issues too: Printer Dialog)). Btw, why configuration dialogs. UI configuration is only modification is only a few clicks away in a xcu file.. so why to trouble design a gui for it ;-).

(In reply to Telesto from comment #3)
> Why needs an image.. be inserted centered on Top..

Because you want to place the picture as close to the cursor as possible. And as commented before it depends on the type of object. Images are supposed to be placed within the text while other objects are treated like figures with white-space left and right.

We didn't change properties for other object types. So it's just bug 87720 that I can refer to. But see also bug 87742.

=> NAB

> => NAB
I can't 'know' if there is a bug here.. without knowing what the settings and behavior of any object ((shapes/fontwork/textbox/frames/caption box/gallery/formula/form element) should be at
(a) insertion time 
(b) single movement (image changes the initial settings pretty quick)
(c) how does an anchor behave with copy/paste.. where should an image/shape land on screen.. 

There are quite a number of cases I really don't understand what's going on.. However do know that 'to paragraph' being far more consistent compared to 'to anchor'.. So the choice to change it from 'to paragraph' to 'to anchor' is in some sense quite a problem. And I haven't seen that as part of the the considerations ;-)..

The current situation maybe workable, but i'm seeing a lot of quirks/ inconsistency's not always good for the general impression. However, my past experience with Word and images wan't great either.. but wait.. the had a 'to anchoring' method for images.. 

* Why a Fontwork is set to: Paragraph text area (vertical) and not to margin?. Does it matter? How?
* Why is an QR code inserted at From Top/ From Left and an image & Chart centered?
* Why is an chart with the cursor at end of paragraph (take ipsum lorem) inserted below the text (centered) and an image in the middle of the text... [same anchor, same positional settings, both centered)
* Why is the fontwork anchor (to paragraph) added to a new paragraph (instead to the existing one) if the cursor is placed at the end of the paragraph
* Why is the vertical position for Formula box disabled (insert formula). But active for inserting a (interactive) frame with Formula style.

This type of phenomenons are - without an explanation - bugs, IMHO. It feels like new objects are created, and developer sets a setting and that's it.. And decisions are made 20 years ago, different times, different world, different programming style.. Different UX questions.

I'm missing the pattern; explanation.. And UX 'should' ideally have documented all the behavior and default settings with an explanation..Else it's hard to check what the proper and wrong behavior is.

Anchor to character pretty weird with a large image.. the anchor is placed below the image.. pressing Enter moves the image down (bug 132948). Not saying it's wrong.. but not user friendly either. 
And the 'handling' of the anchor to character is so weird.. moving (dragging) the image, moves the anchor... I don't think is supposed to happen.. but what the heck do I know about anchoring.. [And we can work around them, but that's not the point; its about the 'ideal'. How is it supposed to work in certain cases.. Some cases might be missed at development time.. 

@going off topic
Why is a image inserted with optimal wrap and a gallery (shape) item with wrap through. A gallery item is for me - benjamin - an image.. Again, maybe be design.. but why? Expect it has always been this way..

I the first place i'm searching for 'answers' to all the oddities (in relation to all insert-able objects ). If it's at the level of ODT standards (Regina). UX (Heiko) or the Developers (not sure who is responsible here). 

There are quite a number of bugs in this area; I think..

Heiko, Telesto, I can understand both positions: Asking for something like a guideline for anchoring to assess, if a current situation is a bug or not (Telesto) and the fact "There is no guideline because all settings are based on individual decisions" (Heiko)

But if there is actual no guideline, the bug is endeed invalid and improvements should be discussed for different objects separately.

(In reply to Dieter from comment #6)
> "There is no guideline because all settings are based
> on individual decisions" 

doesn't match

> But if there is actual no guideline, the bug is endeed invalid and
> improvements should be discussed for different objects separately.

whether NAB or INVALID, point is that I don't see need for the same setting over different objects. Maybe I'm wrong and you get other opinions.

(In reply to Heiko Tietze from comment #7)
> (In reply to Dieter from comment #6)
> > "There is no guideline because all settings are based
> > on individual decisions" 
> 
> doesn't match
> 
> > But if there is actual no guideline, the bug is endeed invalid and
> > improvements should be discussed for different objects separately.
> 
> whether NAB or INVALID, point is that I don't see need for the same setting
> over different objects. Maybe I'm wrong and you get other opinions.

The main point is behavioral differences movement around a document. So I tend opt for same settings, except if there are (valid) reasons do it differently. 

I'm in search for the 'individual decisions' backing those differences etc. I speculate that those are simply history based coincidence. Or maybe based on arguments maybe valid back then but not anymore. However those decisions are old (and not properly documented; i think)  



So major issue is 'lacking of' information. The different behavior is simply 'hard' from user point of view (similar objects different behavior) and keeping quality in control. 
I'm not pointing to an specific bug here. It's more a suggestion to make it easier to find bugs, maintaining over all quality (with basic settings), consistent user experience, directing DEV effort and quick bug fixing. 

All those 'difference' make it hard to asses if something is broken or not. And create the risk of introducing new issues after export to say DOCX/RTF. So streamlining makes it simply easier tho maintain and guarantee basic functionality 

And it makes it possible for the DEVS to focus on certain bugs; instead of bugs scattered across all objects. Where every bug is qualified as corner case, limited to a certain object, with specific anchor/wrap. So object behavior being broken all over the place in different ways, in different settings which all become trivialized individually. 

And no, I don't think people will even notice a change; as it's pretty subtle;in my view.

However to start this assessment I would like the UX-history (log) for the current UX-implementation; how and why did we do this back then? And i'm not going to crawl through they UX mailing list of 10 years (and again the OoO bug list) and maybe the StarOffice documentation :-)

(In reply to Heiko Tietze from comment #7)
> whether NAB or INVALID, point is that I don't see need for the same setting
> over different objects. Maybe I'm wrong and you get other opinions.

Heiko, as far as I understand Telesto, that is not the main idea of this report. Since we haven't a guideline for anchoring (and a guideline could also define different solutions for different objects), it is very difficult to assess for users and also for people in QA, if a behaviour is expected or not and - if it isn't expected - what should be the desired result. Of course we can alway say "Let's ask Design-Team" but that produces a lot of work for Design-Team (and especially for you). So an overview about anchoring would reduce work and would make QA more efficient. 

So bug summary might be wrong and perhaps it's not a valid bug report, but I support that idea (Telesto, do I understand you correctly?)

Guidelines are meant to drive the development not to describe existing behavior. What is missing at the documentation?

https://help.libreoffice.org/latest/en-US/text/shared/01/05260000.html
https://help.libreoffice.org/latest/en-US/text/swriter/guide/anchor_object.html?DbPAR=WRITER#bm_id3147828

This bug is not a regular bug; an incident driven one. It's more about the "bigger picture"; 'vision'. The defaults for the different 'objects' (like: (frame;fontwork;images;textboxes))  There is no straight forwarded answer. So simple bug.. Om looking for the model - reasoning - laying behind all those choices made (in the past). Are those choices still adequate today (evaluation)

I sometimes get the impression that new objects (frame;fontwork;images;textboxes) and such where added incrementally over time. Which did get certain set of insertion defaults. However without consideration coherence between them (each object being unique). So each object has unique combination of 'anchor' + "insertion alignment properties + wraps settings.  Which makes things - unnecessary? - complex :-(. Or their have been 'changes' for 'default insertion alignment settings in the past, which didn't adapt all objects. Causing deviations.  

A) Topic Default anchoring
Historically everything got anchored 'to paragraph'. Currently images / charts are inserted by default 'to character' 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=a7528cd6f17ea5c5b29e7d607e54c62de0d9e7db

However other objects still have the 'to paragraph' anchoring (Frame, Fontwork, Shape). Whereas the reason for changing it for images also valid for the other objects, IMHO. I get the impression those where overlooked. Images are obviously the most common. Or the assumption this would handle all cases? Or simply didn't look into it, because the main concern being images (but breaking coherence in the process)

Not the commit above is being followed by one which makes it possible to 'configure' the default anchor for images if desired

---
B) Topic Alignment
Different objects use different settings (comment 0). I don't' see the advantage of having full range of  of different (default) alignment properties on insertion time for similar objects. 

It sometimes even possible to argue this being a mistake. Fontwork is horizontally Aligned against Paragraph *text* area. Whereas a textbox is aligned at: "to paragraph area". 

There are also inconsistency's for the same object. If you create a Fontwork inside Draw and paste it into Writer the Alignment settings will differ from insertion a fontwork in Writer

The whole stuff simply inconsistent/arbitrary. Whereas it practically maybe less relevance. At least, I drag drop images to right spot. So it goes without report, but this doesn't mean this being desired

And its impossible to know what is good, without design documentation. I not even sure if developers have full insights.. 

C) Topic Wrap
Different objects have different wrap settings. Like: Optimal (images,charts), but bugged, some bug proposing change of default; Through (textbox;fontwork, shapes). Frame (Parallel)

---
Why does it matter,IMO
* Mixing different anchors across the same document by default for different objects without decent reason is sloppy (in my view) (no they historically grown this way isn’t proper reason]. 
* DOCX/DOC doesn't support To paragraph. Which causes conversions to 'to character'. The bugs related to this, caused to change from 'to paragraph' 'to character' for images. However the other objects are affected by the same (only less commonly present) 
* To paragraph and to character anchors have their own particularity's (and might even differ by object.. maybe caused by 'alignment properties'; didn't check!. Reported quite a number of ‘anchoring stuff’
* Not every positioning setting is 'properly tested'. And lots of things are interconnected Wrap + anchoring type/ anchoring position (to character) + alignment settings (when move an object to next page; how should object A position against object B.  
* I'm pretty convinced that those to contribute to bugs like bug 143753/ Bug 131737.
* The default insertion position is mostly not equal to position you desire they object to be (in my view; no data). So not seeing the point having 'unique' alignment settings for each and every object
* A pretty large group -Benjamin? - will likely not be aware of the small differences related to  different (default) alignment settings. The practically don't really matter (if you use drag drop or arrows) Those who have specific wises related to position and size, are aware how those function. And probably change those anyhow

----
Testing perspective
There are plenty of alignment settings options (next, to wrap & anchoring options). This by itself generated an immense amount of combinations. Those will not be tested by QA

You can argue, more using more variants makes bugs more obvious (certainly true). Or you could argue. Lets have a default configuration for all objects, which are 'proven' to work good and being properly tested.

(In reply to Telesto from comment #11)

> A) Topic Default anchoring
> Historically everything got anchored 'to paragraph'. Currently images /
> charts are inserted by default 'to character' 
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=a7528cd6f17ea5c5b29e7d607e54c62de0d9e7db
> 
> However other objects still have the 'to paragraph' anchoring (Frame,
> Fontwork, Shape). Whereas the reason for changing it for images also valid
> for the other objects, IMHO. I get the impression those where overlooked.
> Images are obviously the most common. Or the assumption this would handle
> all cases? Or simply didn't look into it, because the main concern being
> images (but breaking coherence in the process)

Suggestion: Add informations about default anchor in [1], for example:
"To Character: ... This is the default anchor for images, ... and ..."


> B) Topic Alignment
I don't have enough insights to that topic. But perhaps information about alignment could be part of [2]
 
> C) Topic Wrap
> Different objects have different wrap settings. Like: Optimal
> (images,charts), but bugged, some bug proposing change of default; Through
> (textbox;fontwork, shapes). Frame (Parallel)
I couldn't find an overview about different options for wrapping. this might include informtations about default wrap for different objects.

Additional suggestions:
Help [2] says: "You can position an anchored item by dragging the item to another location." More precise would be: "You can position an anchored item by dragging the item or the anchor itself to another location. It's also possible to use arrow keys." 

[1] https://help.libreoffice.org/latest/en-US/text/shared/01/05260000.html
[2] https://help.libreoffice.org/latest/en-US/text/swriter/guide/anchor_object.html?DbPAR=WRITER#bm_id3147828

(In reply to Dieter from comment #12)
> Additional suggestions:
>  "You can position an anchored item by dragging the item or the anchor itself to > another location. 

This still needs some additional information: 
If you drag the anchor (to character) doesn't move, except if you drag it to different paragraph (where bullet counts as paragraph).

Similar for position the image.. If you move the image into new paragraph, the anchor will snap to new paragraph

(In reply to Telesto from comment #13)

> This still needs some additional information: 
> If you drag the anchor (to character) doesn't move, except if you drag it to
> different paragraph (where bullet counts as paragraph).
> 
> Similar for position the image.. If you move the image into new paragraph,
> the anchor will snap to new paragraph

Note 1: the drag the anchor is slightly bugged: bug 144611

------

Note 2: To prevent misunderstanding: My primary concern is that the default settings for objects vary a lot across the board.. I see the current state more as historic process, based on incident & chaos. Like unfinished conversion (anchoring). Some look like mistakes: Paragraph *text* area/ paragraph area. 

The main request being that UX evaluates anchoring, alignment, wrapping defaults for the individual objects and integral 'anchor able objects as a whole'. Keeping in mind that user predictability decreases if you have plenty of objects with all their own defaults. 

It's impossible for me to tell the bigger picture/vision out how the individual objects behave. Or what the merits behind all those individual difference are.
I think those variety of defaults having no purpose at all. Except - possibly - something (extension, unit test) somewhere relying on the current state of affairs.

I'm convinced that there being bugs related to this, however it quite hard to tell right from wrong. 

-----

I do share Dieters view on documentation part (Help). Some kind of UX technical documentation at certain website (wiki) would be nice. Especially if the multitude of defaults are kept.

@Justin L.
This is one of my evaluation requested bugs. The topic is default settings used when inserting objects (shapes, images, charts, OLE).  

Quite a lot of objects having different (default) insertion properties (like different anchor type or alignment settings), making them 'unique'

One example: Images moved to 'to character' for compatibility reasons with Word; all other object still at 'to paragraph'. 

All those settings are naturally (historically) grown into the current state; However it doesn't look very systematic, coherent.   

Input is welcome: including the Word compatibility aspect

(In reply to Telesto from comment #15)
> Input is welcome: including the Word compatibility aspect
Based on all of the bug reports generated by the move "to character" for images, it doesn't seem to be a very good idea to do that for more objects.

(In reply to Justin L from comment #16)
> (In reply to Telesto from comment #15)
> > Input is welcome: including the Word compatibility aspect
> Based on all of the bug reports generated by the move "to character" for
> images, it doesn't seem to be a very good idea to do that for more objects.

A general response, not especially dedicated to Justin 

Point 1: 
A) Can it become worse compared to current state? Images probably most inserted objects (say 80%); so we are 'saving' only '20%'
B) The To Paragraph anchor does behave differently. The mixture is not totally clear for the end-user.
C) Putting everything 'to character' has the advantage of slightly more focus. It does reduce some other bugs; so conversion issues 'to paragraph' 'to 
character'. 
D) I hope you did a search excluding my reports ;-). A single user doesn't represent the whole user base..

Point 2:
Even if decide that this can't be done in the near feature, this still topic for 'long term'.. The 'plan'.  Is the ultimate goal to harmonize the default anchoring or not?

Point 3:
The topic does also include few other aspect aside from anchoring (default wrap & alignment settings) which can be harmonized (fully or partly; at once of step by step). 

Or is someone able the explain why the current insertion defaults - which are different for object by object - are being the right choice. I might have a knowledge gap.. 

Or are we in nobody knows exactly terrain. Where we now it's the default, we assume this being for a reason without insights... And we know that changes mostly cause some unexpected/unintended (side) effect causing an angry mob, so we refrain from doing anything.. The lovely status quo.

(In reply to Heiko Tietze from comment #10)
> What is missing at the documentation?
> 
> https://help.libreoffice.org/latest/en-US/text/shared/01/05260000.html
"To page" could be clarified to specify that "page" actually means "page number"

"As character" is not correct about height of current line.  (or, it is correct only under certain, but not all, circumstances).

> https://help.libreoffice.org/latest/en-US/text/swriter/guide/anchor_object.
> html?DbPAR=WRITER#bm_id3147828
First sentence (and rest of page) is missing critical information (which is also highly relevant to the discussion in this ticket). Here is first sentence.

    An object, such as an image, is positioned within a document using
    anchors attached to other elements.

It is true that anchors "are used" -- but what is missing in that guide is:

    It is also *necessary* to specify the positioning options in relation to 
    the anchor point.  

Simply mentioning the anchoring being used, without specifying the positioning options is more or less impossible to evaluate what will happen with a particular object when text or objects are added or removed from the document.
(and there are additional complications -- but they can be, in principle, addressed in other help pages).

(In reply to Dieter from comment #9)
> Since we haven't a guideline for anchoring ... it is very difficult
> to assess for users and also for people in QA, if a behaviour is expected 
> or not  ... So an  overview about anchoring would reduce work and would 
> make QA more efficient. 
A few suggestions to first responses to "anchoring" reports about objects not positioned as expected.

1. Check to see if positioning options have been provided in the bug report.  If not, then NEEDINFO to get them.

2. If the OP does not report what the person is trying to accomplish, then use NEEDINFO to find out. Many options are available, with remarkable capabilities, but it is necessary to evaluate what a person is trying to accomplish and what positioning options have been chosen to achieve that goal. It is possible that a person has chosen the wrong option (or misunderstands how the option is supposed to operate) in relation to the goal. (In principle: https://help.libreoffice.org/7.4/en-US/text/swriter/01/05060100.html gives full information about positioning options).

  (meanwhile, FTR -- there are several inaccuracies in that page (e.g., bug 148901, bug 148902, bug 148903, bug 148904, bug 148486, bug 148483) and some implementation bugs in some of the positioning options). 

3. If a person starts with the idea that "anchor only" is sufficient for positioning, then it will be impossible to communicate meaningfully or to make reliable STR.  There are interactions between "what positioning is desired" and what positioning options are chosen, which is why it is necessary to know the two pieces indicated in the first two points. 

I believe steps 1 and 2 may help OP and QA to direct their attention and communication in a way that will reduce the need to send queries to Design Team.

(In reply to sdc.blanco from comment #18)
> "To page" could be clarified to specify that "page" actually means "page
> number"

Objection! The page number is also just an object anchored to the page (probably to the header/footer) and it would be misleading to anchor an image to the page number. 

Nevertheless I'd appreciate more under-the-hood information in the online help. For example recommendations and limitations, special conditions etc. But as far as I know the detailedness of the online help was a deliberate decision of the documentation team.

(In reply to Heiko Tietze from comment #20)
> Objection! 
My comment was only to indicate a need for a change in the "To page" entry, not to make a concrete proposal, which I will do here:

To page anchors the object to the physical page in the document where the object currently appears.

This ticket is categorized as "Documentation", but the discussion is more general.  Have opened bug 149253 strictly in relation to:

( Heiko Tietze from comment #10)
> What is missing at the documentation?
> 
> https://help.libreoffice.org/latest/en-US/text/shared/01/05260000.html
> https://help.libreoffice.org/latest/en-US/text/swriter/guide/anchor_object.
> html?DbPAR=WRITER#bm_id3147828
and

(Heiko Tietze from comment #20)
> I'd appreciate more under-the-hood information in the online
> help. For example recommendations and limitations, special conditions etc.
(a) short "tips", "notes" and "warnings" are possible in help pages.
(b) put concrete suggestions in bug 149253.

*** This bug has been marked as a duplicate of bug 149253 ***