Created attachment 167374 [details] Sample document showing the issue with frames' sizes and positions LibreOffice Writer should have an option to make the already inserted frames fully inherit the style applied to them (including **size and position**), so when the style changes, the frame also changes. As it is now, LibreOffice Writer 7.0.3.1 only changes the **position** (and not the size) at most once the frames which had their styles changed, but never changes the frame again no matter how many times the user changes the frame style. Consider the following use case: A page style where page numbers, chapter titles, author names, publication logos, office addresses and other things reserved to be put on headers and footers are formatted with frames to put them on a certain specific position on the page. Or when pictures are inserted on the pages to be always on the left on the page, on the right, or in the middle, with text wrapping after, before or parallel to the pictures. Well, if the frames containing those elements and pictures fully inherited the styles, it would be possible to change the size and position of several elements contained in frames at once (go to Sidebar, Styles, Frame Styles, select the frame style and modify it, go to Type and change its size and position) instead of having to modify frame by frame in the document (as even reapplying the style on the frame don't make the frame inherit the size and position defined on the frame style). All pictures could be formatted as on the right side of the page, with text wrapping on the left, and the user could change it again; all frames containing the page number could have its size changed to be the minimal size needed to show the number instead of being of a minimal horizontal size of 0.75cm (as in the document sample attached). Why is it needed to change those frames by frame styles? Because a document can have many page styles (one for each article in the book, for example, which would need a different header to have a different author name, but the page number has to be formatted the same on every page style) and the difficulty to do it by hand on every style quickly escalates as more page styles are added to the text document. Also, isn't that the purpose of styles, to be able to change everything formatted with them by only modifying the styles? After reading about common styles and automatic styles on the ODF 1.3 specification (https://docs.oasis-open.org/office/OpenDocument/v1.3/csd03/part3-schema/OpenDocument-v1.3-csd03-part3-schema.html#__RefHeading__1415052_253892949) and verifying how LibreOffice Writer saves them when applied to paragraphs, characters and frames (it uses common styles for every non-directly formatted paragraph or characters, but always use automatic styles for every frame, be them directly formatted or not), I understand LibreOffice Writer don't need to add anything new to the ODF standard and still respect the (new) user option to make the frame inherit the frame styles even for its size and position: Just do not save the position and size of the frame object in an automatic style if the user chose to reset them (right clicking on the frame, choosing Properties, Type, Reset), neither store the size on the "<draw:text-box>" tag, so the frame size will inherit from the frame style. In fact, Writer already does that if the tag is manually edited on a text editor to be "<draw:text-box fo:min-height="" fo:min-width="">", but I think it would be best to not even write the empty values and leave only "<draw:text-box>" so to unclutter the file, but Writer doesn't behave the same as if the size attribute tags are defined as empty. My LibreOffice runtime environment while testing the above is: Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: pt-BR (pt_BR); UI: en-US Calc: threaded
Created attachment 167375 [details] Sample showing how Writer behaves as desired (making frames inherit the frame style size settings) This second sample document has a single change from the first: The Line 107 was substituted for: <draw:text-box fo:min-height="" fo:min-width=""> and the Line 79 had 'svg:width="6cm"' inserted so it would be more clear that LibreOffice Writer makes the frame inherit the style size properties when the tag <draw:text-box> has empty attributes. The frame size and position inheritance is a desired feature that would be easily accomplished if LibreOffice saved the ODF tags shown on this comment if the user had an option to make the frame inherit the style size and position.
Not sure, if I've grasped the problem. I tried a sfollows to reproduce the problem 1. I opened attachment 167374 [details]. There are two frames with different frame styles (page number top and page number buttom) 2. I changed style of the first frame to "page number buttom" and style of the second page to "page number top") Result: Position changed as expected. So I can't confirm the problem. If this doen't fit your problem, please add some short steps to reproduce (it's not necessary tw rite a lot) => NEEDINFO
Hi Dieter, thanks for asking! What I am trying to say is that when we directly edit the styles that were applied to the frames (so their set position is changed), the frames themselves don't change until the styles are reapplied to the frames. For example, if I change the "Page number top" frame style so the position of the frame is now on the left side (Press F11, go to Frame styles, modify "Page number top", go to Type, Position, deactivate "Mirror on even pages" and select "Horizonal Left Position", the frame will not automatically change to be put on the left, I'll have to reapply the "Page number top" to the frame so it will change to the left. The second frame, on the bottom, also had to have the "Page number bottom" frame style reapplied for it to go to the left, even if the "Page number bottom" inherits its position from "Page number top". Those frame styles' names on my sample document are a bit silly, as they could be styles for "University logo" (to set the position of the university logo on the document), "Magazine logo" (to set the position of the magazine logo on the document), "Chapter author" (to set the position of the author of the chapter), "Chapter title" (to set the position of the chapter title) and so on, to get more advanced positioning options instead of relaying on those elements being anchored as characters and then editing the paragraph styles. It would be very good for advanced desktop publishing to directly edit the frame styles without needing to reapply them to every frame. Of course, if the user changed manually the position of the frame, by dragging it with the mouse or editing its properties, then the positions should not change (as now the frame would not have the common style applied to it, but an automatic style generated by LibreOffice to set the frame position.
João, thanks for clarification. If you provide steps to reproduce the bug in the following way, it is muh easier to follow them: 1. 2. 3. 4. ... So I tried 1. Open attachment 167374 [details] 2. Select first frame in footer 4. Open sidebar => Styles => Frame Styles (Style "Page number top" is selected) 5. Modify => Tab "Organizer" => enable "Auto Update" 6. Tab "Type" => Position 6. For "Position" deselect "Mirror in even pages" and select Horizontal => Left 7. Press O.K. => Frame doesn't change position (wrong result) Workaround 8. Select Frame again => Change frame Style 9. Change frame Style back to "Page number top" => O. K. => Bug report confirmed; tested with Version: 7.0.4.2 (x64) Build ID: dcf040e67528d9187c66b2379df5ea4407429775 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL
(In reply to Dieter from comment #4) > João, thanks for clarification. If you provide steps to reproduce the bug in > the following way, it is muh easier to follow them: > 1. > 2. > 3. > 4. > ... > Oh, sorry, you are right. My bad. > So I tried > 1. Open attachment 167374 [details] > 2. Select first frame in footer > 4. Open sidebar => Styles => Frame Styles (Style "Page number top" is > selected) > 5. Modify => Tab "Organizer" => enable "Auto Update" > 6. Tab "Type" => Position > 6. For "Position" deselect "Mirror in even pages" and select Horizontal => > Left > 7. Press O.K. => Frame doesn't change position (wrong result) > Step 5. (enable auto update) is not necessary for this bug to happen nor to have it fixed, as this means that if I change a single frame by moving it anywhere, then all frames that have the same frame style applied will change too. Not that an auto update feature isn't useful, but for this bug/enhancement, with the use case I described, the style auto update feature is still optional: What is needed is that after applying a frame style to a frame, it behaves as all paragraphs, characters and pages behave when we apply a paragraph style, a character style or a page style: The object with a style applied will change according to whatever changes we do on the style itself (which is different from changing when we apply another style to the object).
Dear João Paulo, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still present in Version: 7.5.0.1 (X86_64) / LibreOffice Community Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded Additional information: Not sure, if it is relev ant, that attachment 167374 [details] contain a fodt-file.
Still repro and same in 5.2 and 3.5. Arch Linux 64-bit Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fb39ae1bc7e4b1cbfc3108efca52ec310faf7363 CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 14 September 2024