Created attachment 161166 [details]
Example file

Adding UX pro forma, related to bug 133293

From the OASIS standard:

16.37 Graphic Styles
Graphic styles are <style:style> elements that have the family graphic.
In addition to graphic properties, graphic styles may define paragraph and text properties. These are applied to paragraphs contained in drawing objects unless they are overwritten by paragraph styles that are specified by the paragraph elements themselves.

=> NAB

(What bothers me, however, is the fact that users cannot edit this style property except from creating a style as new based on the current selection.)

Duplicate of bug 32484?

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

The anchor is determined by the text:anchor-type attribute of the object. It is not part of a <style:style> element.

Our Frame-'Styles' do not contain only settings from <style:style> elements, but they contain object attributes too. For such attributes our 'style' works as a stamp, that sets the attribute on the object when applying the 'style'.
So if a 'Frame Style' contains the anchor attribute 'to paragraph' it will be set to the object.

I see a bug here. The default anchoring for images was changed to "to character" and the default style is "Graphics". But "Graphics" contains "to paragraph". Therefore default anchoring and default style no longer match in regard to anchoring for images.

BTW: For width and height exists a similar problem. They are object attributes too.

FIXED seems of.. should be NEW i think?

(In reply to Regina Henschel from comment #6)
> character" and the default style is "Graphics". But "Graphics" contains "to
> paragraph". Therefore default anchoring and default style no longer match in
> regard to anchoring for images.

How do we deal with this situation in respect to bug 99646

(In reply to Heiko Tietze from comment #8)
> How do we deal with this situation in respect to bug 99646

I see these problems:
(1) The user cannot set the anchor type, which is stored in the style. Neither the dialog works (bug 99646) nor changing via "Update from selection" works.
(2) Objects are inserted with an individual anchor type, which is not derived from the associated "Frame Style". That results in mismatch in case of "Graphics" (to character <-> to paragraph) and "Formula" (as character <-> to character).
(3) Currently the only way to get an own style, which contains the desired anchor, is, to inherit it from an existing, predefined style. But currently no predefined style exists for "as character".

A different approach than allowing to set anchor type directly in the dialog might be this: Provide a set a basis styles, one for each anchor type. Inherit the predefined styles from them. And a user can get his favorite anchor for the predefined and for his own styles be using the matching basis style.

I think (2) [this issue] can be solved by changing the default styles, independent of a solution for bug 99646.

(In reply to Heiko Tietze from comment #8)
> (In reply to Regina Henschel from comment #6)
> > character" and the default style is "Graphics". But "Graphics" contains "to
> > paragraph". Therefore default anchoring and default style no longer match in
> > regard to anchoring for images.
> 
> How do we deal with this situation in respect to bug 99646

WARNING: Typed before Regina answered...

Changing the anchor from to paragraph to to character 'Graphic Style' is no help for bug 99646. And you can apply Graphic Style to image anchored 'to character' but doesn't change the anchoring at all (no clue why). However if an image is anchored to character and the Graphic Style is applied the anchor changes 'to paragraph

---

@Drifting a little off..
The ultimate/ideal solution is fixing bug 32484. Multiple styles, with different anchors and wrap settings (and aligning; left/right).. And a way to define so select a (temporally) default when importing images.. so the same style is applied over and over.. (but also be able to change that)

And the mouse over info popup should be renamed from 'Frame styles' to "Frame & Image styles". The caption is not clear. And some more differentiation within the dialog wouldn't hurt either.. Frame <-> Image <-> OLE are different objects, IMHO. The technically be the same thing.. but from user perspective totally different. I'm still not sure where the style label is used for.. [not saying it has no purpose.. but frame style feel like a bunch of total different items added together. I actually never considered the formula a frame with a frame style attached to it.. but that's what you get with a Benjamin.. 

And the caption 'Graphic' for Image style still but dubious to me; I personally find it confusing name. [I'm willing to report everything in separate bugs reports, but needs more an integral UX to do list/ minor improvement mock-up , instead of me splitting up every detail in 5-10 separate bug reports, and disuse every point one by one

When reading the title of this bug I'm irritated. The default seems to be set to character in LO 6.4.6.2 an LO 7.0.2.2. So this seems to be changed. But the default style for Graphic shows "to paragraph" instead. Is this a new bug?

Best will be to allow changing the anchor in the style ( bug 32484 ).

Have tested this a little bit more: The anchor has changed since LO 6.4.0.3 but the style doens't show this.

Is there somebody feeling able to solve this bug, giving the user the possibility to change the default behavior for anchor inserting images (and other objects)?
I could make a donation for that.

(In reply to Werner from comment #13)
> Is there somebody feeling able to solve this bug, giving the user the
> possibility to change the default behavior for anchor inserting images (and
> other objects)?
> I could make a donation for that.

They most effective donation would be they donation of the needed code. But I assume this about a financial contribution :P

They issue with financial contribution being that developers are expensive people (and maybe even pricier as employee instead of contractor), so mostly a large sum is needed. Which obviously far to much for what a normal user would be willingly to pay. While aggregating a large sum (crowd funding) failing as they targeted amount not being met; mostly not even close (they few attempt there where floundered)

At that point we are back at square one :-(. 

I personally tend more to they license model. Where they development is funded out of license fee's instead of donations and trying to sell bugfixes/features to (mostly) company's. 
A license model would generate more stable, continuous flow of revenue. At maybe some customer pressure (if you pay license fee you XYZ functioning). And you have argument for that (I paid X). It's broken, disfunctional, fix it :-). 

However currently there is nobody 'responsible'. Developers are happy to solve you're problem, please pay 10.000-100.000$ and we will solve that specific issue for you (and they rest of they would will get it for free). So in fact they eco-system partner/developer is moving their investment risk (without return, because 'shipped for free) to some company/NGO with deeps pockets. But those people not being really inclined to pay.

End result desired features can take for ever.. :-(. Note: stuff is as always more nuanced. And only giving my personal view here. 

Point being: suggestions how to make solve this issue are welcome ;-). There s a fine line/balance between freely available open source office and they commercial interest are here (are large share (3/4) of the code is donated/contributed by (commercial) eco-system partners). 
And there is they problem of cannibalization. LibreOffice free is again so good, so people/company's/NGO can avoid paying (financially or code)

LibreOffice isn't not as good as it could be simply because of money or instead of money bunch of (mostly) C++ developers

+1

(In reply to Telesto from comment #1)
> Created attachment 161166 [details]
> Example file

I just looked at the file since you mentioned this case in https://bugs.documentfoundation.org/show_bug.cgi?id=144629#c4

I tested it with a quite recent development version: 

Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 491678690b5b40f446b40c368ec4b4423ee603c1
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: de-DE
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-09-07_18:32:17
Calc: threaded 

The picture of the cat is anchored as character at the beginning.

But there are two identical "used" frame styles defined in that document:
ABC          (anchored at paragraph)
Bilder

Some more styles show up if I select "all styles". 

But there is only one image! How can more than one "uswed" style?

If I select the frame styles in <F11> and then select the image of the cat, after a few seconds style ABC is highlighted. But the picture is at the left border - contrary to the shown highlighted style which is at paragraph and centered.


If I double click on "ABC", nothing happens. I did not expect that! I expect the picture to move to the middle.

If I double click on the style "Bilder", the cat actually goes to the middle, anchored at the paragraph - as expected.

Simultaneously the style "ABC" vanished from the list (only applied styles should be shown). I consider this to be ok, since there is only one picture and only one style can therefore be applied, in this case "Bilder". If I show all styles, the ones seen before are all present again.

Then I repeatedly applied the defined frame styles one after another. I would expect to see the same arrangements when repeating that! But: try it yourself: Assigning a frame style to a picture depends on which style was applied before - strange!