Bug 144629 - All Defaults for new pictures in LO Writer should be derived from the frame style Graphics
Summary: All Defaults for new pictures in LO Writer should be derived from the frame s...
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.3.0.0 alpha0+
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks:
 
Reported: 2021-09-20 22:21 UTC by Adalbert Hanßen
Modified: 2022-01-31 13:27 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
showing the bug and what it should be (506.56 KB, application/vnd.oasis.opendocument.text)
2021-09-20 22:21 UTC, Adalbert Hanßen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adalbert Hanßen 2021-09-20 22:21:08 UTC
Created attachment 175152 [details]
showing the bug and what it should be

In https://bugs.documentfoundation.org/show_bug.cgi?id=87720#c64 al F complained that not all settings from Frame style "Graphics" change the defaults of the inserted image. One comment earlier I complained about a similar problem. My complaint has been resolved partially in the development version of 2021-09-07_18:32:17 or possibly a few weeks earlier.

Perhaps the relevant code is there almost twice in separate but not completely identical menus
    • Frame style "Graphics" 
and in 
    • Tools > Options > LibreOffice Writer > Formatting Aids

The former is a more complete set and they all should influence the default setting for a newly placed image. Possibly the latter dialog becomes superfluous after all default settings are taken from the style sheet for frames for images.

al F referred to Version 2021-09-07_18:32:17 and he deplored that a few settings from the Frame style "Graphics" do not become defaults to an inserted image and he asked to make all the settings in the style sheet become defaults for newly pasted graphics.

Steps to reproduce: 
1. define the preferences in the frame fro an image in the style sheet, especially anchor to paragraph.
2. make some screenshot of different sizes
3. place them to adjacent paragraphs to a the document with the styles defined in step 1.
4. Observe which of the parameters settable in the style sheet are used as default and which of them are taken from some other default. Not all position parameters do become default, see attachment. But there may be more than those mentioned there.

Result: The screenshots sometimes get placed strange when they would otherwise cross the page border. Sometimes they extend into the footer area. This can be avoided by positioning them to the paragraph text area each.

Further I would prefer it if in the properties dialogue for a graphic object in the tab Type the check mark for Keep ratio would be initially checked (currently it is off by default. I have heard that this is hard coded. Presetting it on that would require minimum effort then).

At least Anchor to paragraph has become possible meanwhile in the development branch. However not all position parameters are accessible through Tools > Options > LibreOffice Writer > Formatting Aids > Anchor. All default settings could be taken from there making the other dialog superfluous.
Comment 1 Regina Henschel 2021-09-20 23:45:34 UTC
The situation is difficult in regard to anchor type, because an anchor type can be determined by an attribute in the assigned graphic style and its hierarchy, and it can be directly determined as attribute of the object. If both exists, the latter "wins".
LibreOffice currently writes always the direct object attribute and has no UI to set the anchor-type in a style. There exists the option for the default anchor type. However that does not set the default in the "graphics" style, but is only used to determine the anchor-type which is set at the object when inserting it.

Taking "all" properties would not be good, because that would include width and height. But images should get their initial size from its intrinsic size, not from a style.
Comment 2 Heiko Tietze 2021-09-21 06:49:28 UTC
We have 116 tickets with "image" and "anchor" in the summary (most filed by Telesto). That's way too much for an overview. And most likely this one has a duplicate.

Regina's comment sounds to me as if we should resolve the "all defaults" as WF. When I insert an image with a previously modified Graphics style it works as expected (anchor as character, border active, for example).

Can you be more specific?
Comment 3 Adalbert Hanßen 2021-09-21 08:25:22 UTC
(In reply to Regina Henschel from comment #1)

Thank you for your explanation. But I do not understand this completely:

> The situation is difficult in regard to anchor type, because an anchor type
> can be determined by an attribute in the assigned graphic style and its
> hierarchy, and it can be directly determined as attribute of the object. If
> both exists, the latter "wins".

About what hierarchy are you talking? Is it when there are several graphic styles g1, g2, ... and the settings of "based on" in the management section of styles? 

I have created another style for an image with anchoring "als Zeichen". However I was unable to do it with New Style in <F11>, but only by manipulating the style of an existing image and the unse "New style from selection".

When I paste a new screenshot and look at <F11>, it is shown as if the first style was assigned to it (without regard to what graphics style was used last). This is the one which I consider default (or no special style) and which should be called accordingly. 

Even if an image was selected before and its assigned style is highlighted under frames, during pasting <F11> changes to the paragraph styles when clicking to set the anchor point. As soon as the image is pasted, the category switches back to frames and shows the newly pasted image with the first frame from the list associated to it Therefore I consider this one to be the default one - right?.

After pasting an image  I can assign another existing style to it by doubleclicking on the other style in <F11>. In my trial it had a different anchoring assigned to it. 

I conclude that it is possible to provide styles for differently anchored images! There might been a missing path to create it by new style however.

Since styles for differently anchored images can be provided, as many settings as logically possibly should be taken from the assigned one, especially the ones from the position section and also the extra space from the "Umlauf" section. Currently I see no one which has to be excluded logically, but I might be wrong. In this case the non-applicable parameters should be flagged accordingly to stop the endless discussions deplored in the next comment. 

As many settings as possible should be therefore taken from what I consider the default one when initially pasting an image. As many settings as possible should be taken from the assigned one one when later assigning another style to an image.

> LibreOffice currently writes always the direct object attribute and has no
> UI to set the anchor-type in a style. 

My observation seems to be different, see above.

> There exists the option for the
> default anchor type. However that does not set the default in the "graphics"
> style, but is only used to determine the anchor-type which is set at the
> object when inserting it.

This is consistent with my observation: It seems to be the first style from that category.

> Taking "all" properties would not be good, because that would include width
> and height. But images should get their initial size from its intrinsic
> size, not from a style.

Concerning width and height: In the German version they are described as minimum height and width. That's meaningful and can always be done: i.e. if the inserted object is smaller, it is enlarged until both criteria are met. If the aspect ratio is locked, it should be done respecting that too.

Note: During my trials today it happened once that my image was shrunk to zero height (although I was not playing with that parameter). I was not able to reproduce that one, but there might be an error around there. Please keep an open eye on that if you encounter it.
Comment 4 Telesto 2021-09-21 17:42:50 UTC
The see also should be relevant based on superficial reading. Also bug 133291 comment 6
Comment 5 Heiko Tietze 2022-01-31 13:27:38 UTC
Needinfo for several month now, unclear what exactly is requested.