Bug 140424 - Changes for Frame styles in Type tab don't work
Summary: Changes for Frame styles in Type tab don't work
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Styles-Frame
  Show dependency treegraph
 
Reported: 2021-02-15 11:11 UTC by ajlittoz
Modified: 2023-07-21 05:11 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Margin notes as a collection of frames (18.22 KB, application/vnd.oasis.opendocument.text)
2021-02-15 11:11 UTC, ajlittoz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ajlittoz 2021-02-15 11:11:02 UTC
Created attachment 169756 [details]
Margin notes as a collection of frames

Sorry if this is not the right channel for it, but it may also turn into an enhancement request.

This is a follow-on of https://ask.libreoffice.org/en/question/293360/how-to-warp-text-only-on-two-out-of-four-columns/ where I solved the challenge with the attached sample document.

The question was among other things about having both footnotes and margin notes.

I solved the margin notes issues with a frame style configured so that Writer will solve the position conflicts by itself. In other words, the Allow overlap checkbox in the Wrap tab is unchecked.

Formatting in such a document is very complex and can be brought to a satisfactory state only after trial and errors.

With style philosophy, this means you modify a style and press Apply or OK to see the visual formatting result.

It works fine with paragraph, character, page and list styles. However, it does not work with frame styles. When a frame style is updated, nothing happens. You must apply a different style and reapply the original style to have the update effective.

In the case of the attached document, the margin notes are all inserted in the same position and they are shifted downwards due to the disabled "Allow overlap" setting.

If I do the trick above on one of the frames, it is not correctly repositioned among the others and the whole layout is messed up. I must do the stance on ALL the frames and reapply the original style in the correct order for the notes to be repositioned.

The question is: why don't the style modification update the frame instances? Is there a design issue in frame processing which prevent this update as with the other style categories?
Comment 1 Regina Henschel 2021-03-02 13:44:40 UTC
(In reply to ajlittoz from comment #0)
> 
> With style philosophy, this means you modify a style and press Apply or OK
> to see the visual formatting result.
> 
> It works fine with paragraph, character, page and list styles. However, it
> does not work with frame styles. When a frame style is updated, nothing
> happens. You must apply a different style and reapply the original style to
> have the update effective.

I cannot confirm this. When I set e.g. a border or a background in your frame style "Left Margin Note", then all three frames update to the new appearance immediately.
Comment 2 ajlittoz 2021-03-03 09:43:53 UTC
(In reply to Regina Henschel from comment #1)
> (In reply to ajlittoz from comment #0)
> 
> I cannot confirm this. When I set e.g. a border or a background in your
> frame style "Left Margin Note", then all three frames update to the new
> appearance immediately.

Yes, it works for all attributes but for those in Type tab. Try to offset the frames horizontally, changing position from 0.5cm to 2cm: the frames remain at their present position until you assign another style and again the original one.

With such a sophisticated layout, tuning is needed mainly on position. This can only be done in the Type tab, Position section. Unfortunately this does not work.

The intentional conflict on frame position cannot be blamed because changing the parameters in the simple case of a margin icon anchored to a paragraph does not work either. Think of a "warning sign" to flag a paragraph as important. The icon is usually put in the left margin. If you want to send it in the right margin, changing Left page border to Right page border has no immediate effect. You must follow the stance: other style then back to modified style.

This is not user-friendly and, in the case of this complex layout, has bad consequences because it messes completely the ordering of the frames.
Comment 3 Regina Henschel 2021-03-03 14:59:38 UTC
(In reply to ajlittoz from comment #2)
> Yes, it works for all attributes but for those in Type tab. Try to offset
> the frames horizontally, changing position from 0.5cm to 2cm: the frames
> remain at their present position until you assign another style and again
> the original one.

I consider this a bug. I see the error in Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: e60bebd4c5257b0f592d27c74399de1498ac725b
CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL

For problem with predefined size see bug 138289.

BTW: For to get objects in page margin automatically positioned correctly on right and left pages, use the check box "Mirror on even pages" on tab "Type". But do not use horizontal position "center" because of bug 65412.
Comment 4 ajlittoz 2021-03-03 17:24:34 UTC
(In reply to Regina Henschel from comment #3)
> 
> For problem with predefined size see bug 138289.
> 
It looks like an exact duplicate of this report.

> BTW: For to get objects in page margin automatically positioned correctly on
> right and left pages, use the check box "Mirror on even pages" on tab
> "Type". But do not use horizontal position "center" because of bug 65412.

My point was not specifically about mirror layout but thanks for informing me about this bug which is also really annoying.
Comment 5 Regina Henschel 2021-03-03 19:30:25 UTC
(In reply to ajlittoz from comment #4)
> (In reply to Regina Henschel from comment #3)
> > 
> > For problem with predefined size see bug 138289.
> > 
> It looks like an exact duplicate of this report.

I think, that are different problems. The anchor type and position is independent of the size. I personally do not want, that the size of an object is integrated into a style, because that produces distortion, when the style is applied to an object. You get this problem currently, when you update the style from an object and then apply the style to an other object. Where as type and position is desirable for to set objects quickly into the page margin, for example.
Comment 6 ajlittoz 2021-03-03 19:57:51 UTC
(In reply to Regina Henschel from comment #5)
> (In reply to ajlittoz from comment #4)
> 
> I think, that are different problems. The anchor type and position is
> independent of the size. I personally do not want, that the size of an
> object is integrated into a style, because that produces distortion, when
> the style is applied to an object. You get this problem currently, when you
> update the style from an object and then apply the style to an other object.
> Where as type and position is desirable for to set objects quickly into the
> page margin, for example.

This is where it is very difficult to define a behaviour satisfying all users. Even in my sole case, there are times where I want the size to be part of the style and times when I don't.

Can this be managed through the use of the AutoSize check boxes combined with minimum sizes? when unchecked, dimensions should apply; when checked, the frame keep its present dimensions constrained by minimum size.

I don't know if this proposal makes sense because I have no example at hand.

An extra question:

Why isn't the anchor type part of the style definition?

Some built-in styles contain an anchor type, e.g. Formula is As character while Frame is To paragraph. Thus when creating a custom style with a forced anchor mode, I must derive it from one or the other. If anchor mode could be configured in the style definition, this would be easier. Eventually, there could be a "None" anchor mode so that the style does not change the anchor mode when applied to an existing frame. Of course, this "None" mode must not be offered elsewhere than in style definition. In other words, it must not appear in Insert>Frame direct creation.
Comment 7 Regina Henschel 2021-03-03 20:53:10 UTC
(In reply to ajlittoz from comment #6)
> 
> An extra question:
> 
> Why isn't the anchor type part of the style definition?

Because of bug 113381 you currently cannot use only the style, but you need to use a direct formatting, which then refers to the style. When LO applies a frame style, it copies the anchor info into the direct format of the object.

I don't know why this design has been introduced, likely a problem inherited from StarOffice (https://en.wikipedia.org/wiki/StarOffice), at least since OpenOffice.org 1.1 such problems exist.
Comment 8 ajlittoz 2022-08-03 14:20:13 UTC
Bug still present in 7.3.4.2