Style frames to be at an edge but not overlap

[dolezvo1]

I’m not sure if there is any way to do this, but I’d like to be able to anchor frames to a paragraph, and have the frame appear at an horizontal edge of the page*. It doesn’t really matter to me that much if it is before the paragraph or after it, or if it’s always top/bottom, or nearest one, or something like that.

I tried simply setting the style position to bottom of the page text area, but the issue is that if there are multiple frames on one page, they overlap.

Expectations:

Reality:

I understand that aligning the images at the bottom is likely not going to be possible just by using simple styles, because it would mean that Fig.1 would have to be moved up to accommodate Fig. 2, etc., but maybe there is at least some trick to do it at the top of the page? Or more generally, is there any way to have the frames automatically layout in a somewhat nice way?

[ajlittoz]

@dolezvo1

I understand that aligning the images at the bottom is likely not going to be possible just by using simple styles

No. You can request automatic re-adjustment when there is a conflict but this is tricky and requires very careful configuration of frame style.

Be aware that automatic offsetting tries first in the horizontal direction. So, to get vertical adjustment, positioning parameters must be correctly selected.

Frame styles are very difficult to tame in order to get what you specify from start. In particular, they accept absolutely no direct formatting superimposed on them, lest the frame style becomes completely ineffective (contrary to paragraph or character styles).

There is also a surprising default setting where Allow overlap is ticked in the Wrap tab (I don’t understand why it changed several releases back from unticked to ticked because usually expect frames or images not to overlap).

Since the configuration depends on many factors, attach your sample file as a test case (degrade image quality so that total document size is under 3 MB – what I need is the correct frame size with something in it; full details are not useful). Mention OS name and exact LO version (important because there are been changes in frame management lately). Save format will be determined from your sample. If it is not .odt, you case is hopeless because alien format have no notion of frame style.

[ajlittoz]

@dolezvo1
You ticked my comment as the solution. I was only describing a few leads. Which one put your on the right track? The Overlap box? But you may also need to tick Keep inside text boundaries to avoid shifting the conflicting frame into bottom margin and having it neatly sent to next page.

[dolezvo1]

Yeah, I apologize, I was being too optimistic. I tried messing with the settings again, and it briefly seemed to be working, but it probably wasn’t really. I did notice the Allow overlap checkbox before creating the post, and turned it off, but I didn’t really notice it changing anything.

frame_anchor.odt (12.3 KB)

[ajlittoz]

From quick experiment, it looks like the bottom-of-page constraint does not work. In a sense, I understand it:

• the first frame is positioned at bottom of page
• the second frame conflicts, requiring the same position
• conflict resolution tries to put it below the first one but then the frame overflows in the bottom margin
• a possibility would be to shift upwards the first frame but text may already have been set in this area
  To avoid recursing flow problems, Writer gives up and overlaps both frames despite the requirement.

I compared with one of my documents (ComplexLayoutExample.odt (43.7 KB)) to see the differences. I positioned the frames at top and they can extend “freely” downwards.

So if you accept to put your frames at top of page, problem is solved. Interaction with text is correctly handled (I checked).

Remark: you captioned an image, i.e. Writer created an outer frame containing the image and the caption paragraph. I want to emphasise that frames do not nest. Size of the outer frame has been computed by Writer at time of captioning. Vertical AutoSize is ticked but it takes only text into account. If you later resize directly the image, the outer frame won’t adapt because frames don’t interact with each other. You may end up either with a smaller image in the original caption frame or an image overflowing the caption frame.

PS: congratulation for your frame configuration and the absence of direct formatting on the frames. Your frames should correctly react to document edits (apart from the Bottom dysfunction).

[dolezvo1]

Thanks for the insight and for sharing the document. In hindsight I can see that most of my issues were probably caused by using Position: Vertical: Top setting, instead of Position: Vertical: From Top. With that setting, the frames really do stack in a natural way, at least some of the time. It seems that there is a difference depending on whether the frames are anchored to the same paragraph (in which case it just works as expected for me) or not (in which case the frames still do overlap when on the same page). In the case of your document, I would imagine the engine can make it work because it does not have to take the anchoring text itself into consideration. I think that’s good enough for me, though.

[ajlittoz]

Top and From Top behave the same. In my document, the poster requested that the first frames be positioned a bit below the top of the text so that in pages with a heading margin notes would not be aligned with the heading.

Indeed, the fact that the frames are sent into the margin makes things a bit easier because Writer need not care for conflict with text. The request was "how to create margin notes, similar to footnotes, with automatic positioning.

Anchoring to same paragraph or not should not matter.

[dolezvo1]

Top and From Top behave the same.

Huh, you’re completely right. Thanks for pointing that out.

Anchoring to same paragraph or not should not matter.

I’m pretty sure it does for me, but it might not be intended. What version are you on? I’m using 26.2, so that might be why.

[ajlittoz]

LO 25.8.2.2, Fedora 43, KDE Plasma desktop