Created attachment 204704 [details] Example of bad behaviour (header not expanded) LO 25.8.3.2, Fedora 43, KDE Plasma desktop Frame wrap properties are used to "protect" text from frame interaction. Wrap allows to define areas where no text will be laid out. To some extent, position of frame also modifies paragraph bounding box. This is the case when reference position is paragraph_text_area or entire_paragraph area. Since "bottom" is buggy (will be described in a separate bug report), I'll focus here on Top position. Top + Paragraph_text_Area: the frame is located between spacing_above and paragraph text. With Wrap off, the net effect is to add the frame height to the text rectangle (with text starting below the frame). Top + Entire_paragraph_area: the frame starts at top of spacing_above. If the latter is high enough, nothing special happens: the frame is totally contained in spacing_above. If there is not enough room with Wrap off, spacing is added between spacing_above and text to hold the frame. This works fine in main text flow. However when a frame is inserted in the header, wrap properties are ignored: - Wrap off does not create white protected area on both sides of the frame - The presence of the frame does not modify the anchoring paragraph bounding rectangle. A subsequent paragraph is not offset below the frame+paragraph. - The header is not expanded to host header text + associated frames though the page style is configured for AutoFit header height. Consequently the frame bleeds into main text area. Note this is different from a watermark where the position is rather relative to the whole page instead of a header paragraph. And generally, a watermark is sent in the background. All frames in the attached document are formatted by the same frame style. They should behave identically. Allow_overlap is unticked in an attempt to solve the conflict between the header frame and the first frame in the document. This does not work, probably because the header is cached somewhere, independent from main text (main text does not exist yet when the header is first built; this cache is then inserted "as is" over and over in new pages and text layout begins afterward without caring for "bleeds"). Another attempt was to tick Keep_inside_text_boundaries. This caused the frame header to be clipped to the size of the header computed from the paragraphs (again without taking the frame into consideration; but its wrap properties are ignored). ----- Is there any reason in ODF to curb frame behaviour in headers (and probably footers too)? If so, what was the anticipated fear? I'd like these limitation be removed. Frames are an advanced feature and those who use them are supposed to know what they're doing. ----- This bug report is more or lesss a follow-on for https://ask.libreoffice.org/t/writer-wont-line-up-bottom-line-with-images-of-different-immutable-heights/130068/
I think, I can confirm the report with Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 680(Build:0) CPU threads: 12; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded Steps: 1. Open attachment 204704 [details] (text "Para below frame" is left of frame in header) 2. Copy frame and text in header 3. Paste frame and text in text area => text "Para below frame" is now below frame (expected) Actual result Wrap properties are ignored, when frame is in header Expected result Behaviour should be the same as in text area