Frame style still not updating frames correctly

I don’t know why forum post “Writer: frame style doesn’t update” was closed. The bugs referenced therein are also not resolved.

Over 15 years ago, I migrated a large collection of documents from Publisher to LibreOffice Writer. I used styles extensively. I had no issues with frames updating whenever I updated the related styles.

Fast forward to last week and this week. I am trying to migrate a simple 18 page document and once again attempting to use styles exclusively to facilitate future changes en mass. And I have tripped over really weird frame style behavior. For example, I can increase the vertical size and see all frames updated correctly. But if I attempt to decrease the vertical size, none of them update. And just now, somehow, I got one single frame to increase and decrease the horizontal size, but none of the other frames related to the same style reflect the changes! It’s the most bizzare issue I have seen in a while.

Are frame styles really that broken? And if so, why is no developer able to focus on this and fix it? The online LibreOffice book strongly encourages the use of styles. In fact, it says that LibreOffice is a “styles-based program.” Yet styles seem to be half-baked to me. They used to work. But someone broke them between that time I used them before and now.

I opened a new bug report at 166394 – Applying frame template changes only updates size if size is greater than before. Based on how the other bugs were handled, I have low confidence mine will be addressed any better. :frowning: I was hoping to migrate my father from Publisher to LibreOffice since the former is going end of life next year. But now I have to seriously reconsider this.

I cannot reproduce this in my case.
Please specify which operating system and which LibreOffice version you are working with.
Did you do the conversion 15 years ago, or do you only convert when necessary?
How do you make the changes, directly in the frame style (which one), or do you right-click and select Properties?
Is there any direct formatting from the conversion?


To be able to help, it would be useful if you could upload a sample file (MS) here. Thank you.


With me:
Version: 25.2.3.2 (X86_64) / LibreOffice Community
Build ID: bbb074479178df812d175f709636b368952c2ce3
CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL threaded

Frame styles are indeed less “bullet-proof” than the others (paragraph, character, page and even list).

Their main weakness is to be over-sensitive to direct formatting, even the most inconspicuous forms (such as dragging a frame with the mouse).

I have noticed that sometimes update does not occur if I modify a frame style while its frame is selected. The workaround is to apply any other frame style, preferentially not in the inheritance chain, then re-apply the updated style.


I read your bug report and followed your steps. I don’t incur your issue (Fedora 42, LO 25.2.3.2). So, attach a sample file so that I can analyse it, notably the state of AutoSize and other parameters.

I repeat: frames are extremely sensitive to direct formatting (DF). The mere suspicion of the presence of a shadow of DF is enough to disable style settings. Tell us if you moved the frame with the mouse (drag) after you’ve created it and before you applied the style.

Writer: frame style doesn't update

Migration from AskBot
as opposed to Ask/Guide - How to use the Ask site - The Document Foundation Wiki #Mark_an_answer_as_Solution

rhetorical question probably, but hint : you may ask (all of) them individually : Professional Support | LibreOffice - Free and private office suite - Based on OpenOffice - Compatible with Microsoft

And to dig further into your question, maybe a useful reality check :
https://www.documentfoundation.org/
https://community.documentfoundation.org/t/some-thoughts-on-the-libreoffice-ecosystem-and-the-future-of-the-libreoffice-project/12531
https://community.documentfoundation.org/t/vote-technical-budgeting-procedure/9520/18
https://community.documentfoundation.org/t/some-propositions-for-tdfs-future/11475
etc …

at least you’ll join the hundreds in the list :wink:
Dependency tree for Bug 107656
image

buf of course : Donate to LibreOffice | LibreOffice - Free and private office suite - Based on OpenOffice - Compatible with Microsoft

Operating system: Debian 12 (bookworm)
UI: KDE Plasma (X11, not Wayland)

I migrated a large collection of documents 15 years ago because they needed to be usable by people without Publisher. I created the documents using page styles, frame styles, and paragraph styles, and frame linking without one issue with styles.

Last week and this week, I progressively created the frame styles, fleshing them out as I went, assuming that re-applying a frame style to a frame would overwrite any changes to the frame itself. So I was messing with both until I got what I wanted. Then I updated the frames to precise spec, reapplied them to all the relevant frames, and expected that any further changes to the frame styles would automatically apply. They did not.

I think the logical design & implementation specifications would be that (1) changes to the frame break dependency on the frame style, but (2) reapplying the frame style (by apply another style and then reapplying the original style, for example) would restore this dependency.

I will attach a sample file.

Side note: Please do not complain about the formatting of this reply. I am formatting it correctly as seen below. But when saving, the forum removes all my paragraph separation:

@fpy I’m not sure what you mean by your reply or what you are suggesting, except perhaps that I donate? Forgive my frustration. I had just read the other two bug reports and realized this issue has been a problem for years. I couldn’t fathom how such a core feature would be so buggy. I would rather have bugs squashed than more new and fancy features. But perhaps not many people really use styles and even less frame styles, so it’s very low on the “totem pole” of things to fix. I just also could not understand how it got so broken over the years. I apologize for the frustration that came through my post.

@ajlittoz I have attached it at the bottom.

Per my response, I was not aware how unstable this functionality is. For example, I have certainly tinkered with the frame itself, getting it to look right, and then updating the style based on the frame. Then I expected all the other frames to update based on the style. I also expected a frame to update based on changes to the style after “reapplying” the style to the frame (i.e. after overwriting any and all changes made directly to the frame). But it appears I still have to “reapply” the style to ALL the frames, one by one, by applying another style and then the former. Apparently I have to do this after any updates to the style, forever and beyond. I figured that once a style was applied, I could simply make changes through the style and see them reflected on all the associated frames. The expected outcome seems unattainable.

@TitaniumCoder477
Please, don’t use “Suggest a solution” for information which is not precisely a solution. A sample file can be attached to a comment, too. Best, reopen your question (to enter edit mode, click on below it, then on the “pencil” icon) to provide requested and required details so that everything is in a single place (this site is not a forum; there is no such thing as a thread or conversation).


As I suspected, you have direct formatting on your frames (and I also found character DF for italics).

This DF is very subtle: you changed the height of some of your frames by a very small amount, e.g. width of 9.58cm instead of style 9.55cm. This tiny difference (unnoticeable by eye) is sufficient to tell Writer you manually applied some override. As I mentioned frame styles are not at all “bullet-proof”. This override, instead of forcing only this parameter, will cause all other individual parameters in the frame to take precedence over the style. And there is no provision to clear direct formatting. The only workaround is to apply an unrelated style like Formula (which also changes the anchor) before reapplying the target style.

You can tell the presence of DF on frames by comparing settings from right-click + Properties and style configuration.


I also don’t understand the logic behind your frames. You seem to have blindly transposed the structure in Publisher (which is page-oriented like all desktop publishing programs DTP) while Writer is flow-oriented which compelled you to simulate the difference in behaviour with tons of frames (and the consequent performance penalty).

The links between your frames seems buggy. The very first frame at top left links to ??? (Is it the frame at top right on next page?) When I reduced the height of the first frame, text does not spill over to the second frame. I get a small red triangle flagging text clipping.

It looks like you want to simulate a booklet one-third height from your chosen paper size. Why then don’t you set this height in the page style?

You make your life difficult too by anchoring your frames To page. This is indeed a DTP feature (and if you want to mimic Publisher behaviour, this is a good choice, but I am not sure you grasp all the consequences). But you immediately lose all the automatic layout function in Writer.

You have footnotes. Your frame layout (and particularly the To page anchor) compels you to handle your notes manually (consistent numbering in text and at bottom, formatting, position …). Managing your document is certainly a nightmare.


IMHO, you should think over the specification of your document, describe precisely what you want to achieve. Obviously, the narrative defines a text flow (perhaps you have several narratives – how do they interact with each other?). How could you insert your narrative(s) and layout in the Writer workflow? I think this is more fruitful than trying put your feet in too narrow shoes.

One last word about your usage of styles: you named them according to their visual effect. This is wrong. Your styles are in fact a semantic markup. You can keep built-in Body Text for your main topic. When paragraphs look like headings, why don’t you use Heading n where n hints at the level or importance of the heading (1 most important, 2 important, … 10 least important)? When you want to emphasise a group of word, use Emphasis or Strong Emphasis. And so on for comments, advices, notes, quotations, …

The appearance of text is just a matter of configuring the styles. And since their names are related to significance, you know exactly what this impacts.

As a counter-example, take tBlue which seems a surrogate for Strong Emphasis. What happens if your printshop requests a change of colour because the tint of the paper reduces contrast and reading comfort? Do you reconfigure tBlue to become dark brown? Then the name tBlue no longer makes sense. Also, are you sure that tBlue-tagged sequences all have the same significance? You may have used tBlue both for emphasis and for special purpose (like URLs). If you change tblue to reinforce emphasis, does it make sense to also change URLs?

Attached is the file.
Dad’s Tract.odt (39.3 KB)