Frame around paragraph extends to embedded object of previous paragraph

English
#1

Consider the attached document. There are two paragraphs. The first contains an embedded object (a table in this case) anchored to that paragraph and configured such that it is shown below that paragraph (without floating). The second paragraph below the first one (and below the table) is configured to have a visible border. For some reason, the border is extended to include the table:

grafik
grafik831×113 23.7 KB

Is there any way to make the border not include the table (which is supposed to “belong” to the first paragraph, not the second)?

odt-Document: test.odt (15.7 KB)

LO version:
Version: 25.8.3.2 (X86_64) / LibreOffice Community
Build ID: 580(Build:2)
CPU threads: 12; OS: Linux 6.6; UI render: default; VCL: qt6 (cairo+xcb)
Locale: en-US (de_DE.UTF-8); UI: de-DE
Calc: threaded

#2

Your “table” is in fact a Drawing Object. Drawing objects interact quite erratically with text. They are intended for small decorations when you can’t obtain the same effect with standard text features. In addition formatting drawing objects is cumbersome because you can’t use styles (both on the object itself to get automatic repositioning and inside it on text).

I think this is an example where Writer has difficulty to relate the drawing object with its paragraph and compute the bounding rectangle to your expectation.

I’d rather suggest you Insert >Table at the end of the first paragraph. Then you have a primary Writer object (a table) which is nicely managed in the text flow.

For your own peace of mind, select None style when creating your table to avoid bad “surprises” when the table decides to repaint itself without your explicit consent.

PS: when asking here, always mention OS name, exact LO version (not “latest” which does not mean anything) and save format (inferred to be .odt according to the sample).

#3

Thanks for your response. Actually, there is a good reason that the table is a “Drawing Object” … in the real use-case those objects come from external documents and recreating them in writer is not really an option (it might be possible for that small table, but that is just an example).

I added the missing information to the first post.

#4

Are they images? Images could be easier to fix because you can apply a frame style to them.

#5

No, complex tables, drawings, text boxes, ole-objects of all kind etc.

#6

You could

  1. Add an empty paragraph below the first paragraph
  2. Select the table and drag it to the empty paragraph (if it doesn’t occupy the new space automatically)
  3. Right click the table and click Anchor > As Character
  4. (Optional) Right click table, select Properties > Wrap and set the Spacing > Bottom to 0.2 cm or 0.3 cm
#7

Thank you for your suggestion. This somehow works, but it still is (imho) an ugly workaround. I had to change every single included object in my document.

As an additional comment: If the paragraph below the object has explicit spaces, the result is even more unexpected. In the following example (test2.odt (16.3 KB)) the second paragraph has a colored background, a border and a 2cm space above:

grafik
grafik810×269 36.2 KB

So the border/background is not really extended to include the object but for some reason “automatic space” (caused by the object) but not “forced space” (caused by explicit setting) is included. Now I could set this space manually to some value roughly the height of the table and the visual result would be okay. However, then I could not, e.g., resize the object easily without having to change that spaces manually. And it does not work if there is a page-break just before the second paragraph but after the object (because the large forced space would be visible on the page of the second paragraph).

#8

In what way does Anchor as character not work?
You could even set that as default anchoring for Writer so that newly added objects take the As Character anchor as default, Tools > Options > LibreOffice Writer > Formatting Aids and set Anchor to As Character.

test2_129982EA.odt (16.9 KB)

#9

Obviously, Writer is quite confused.

It correctly displays the 2cm space above the second paragraph.

But the drawing object disturbs computation of the second paragraph text area. The drawing object is supposed to be positioned at bottom of the first paragraph text area, thus it should only interact with the global bounding rectangle of the first paragraph. Unfortunately, it behaves as if requesting some real estate from the second paragraph with an “incomplete” height.

I think “bottom of xxx paragraph” is buggy. I already had serious problems on frames with this position and have ruled it out from my documents. Apparently, behaviour is the same with drawing objects.

What do you mean with “automatic space”? There are no such option. Are you thinking of the standard layout algorithm in Writer?

#10

By “automatic space” I mean that there is some space between the first and the second paragraph (necessary for the table). The second paragraph is shifted down so that it does not overlap with the table. That is fine. But for the drawing of the border/background, the paragraph still seems to start right below the first paragraph.

#11

In theory (if the feature was exempt from bugs), position “bottom of paragraph text area” extends the area occupied by text: your drawing “becomes” an element of text and included in the text rectangle. Space below is added below this new rectangle.

Here, this does not happen. The drawing object is laid out immediately below the last line of the paragraph (where it should be) but its size is not reported to the text rectangle as if the drawing object did not exist. This is a first bug.

Then we have space below from the first paragraph and space above of the second. The second bug appears now: for an unknown reason a fraction of the drawing object height is added as a wrap area at top of the second paragraph, extending its text area (as shown by the background).

If I move the anchor into the second paragraph and change position to “top of paragraph text area”, I get the expected result.

Unfortunately, there is no way to position the drawing object inside “space above” automatically. From experiments, it looks like the paragraph text area is increased by half the difference between the drawing object height and space_above.

I feel that “bottom of xxx paragraph” position defers layout and hands it over to next paragraph. This is probably the cause of the bug if I guess right.

#12

I did not say it does not work. It does. It is just not the way I want the objects to be included in the document (for other reasons not discussed here). I know that I can achieve the same (or nearly the same) visual result by doing things differently. But that’s not the point. I just wanted to know if there is some (formatting?) option/setting/whatever that I am not aware of that makes the border to appear the way I expected. If there is no way to do this and I have to use some workaround, that’s fine (I just want know).

#15

Hm. What is the expectation? You describe a buggy behavior on a user-to-user site; since it’s buggy, fixing it properly is out of option on a user-to-user site, and workarounds (of different degree of ugliness :slight_smile:) are the only possible result :slight_smile:

#17

Basically I hoped for one of the following answers (starting with the most preferred one):

  • I did something wrong, I overlooked the following setting/option which just has to be changed.
  • The described behavior is exactly as it is supposed to be (maybe with a link/reference to the explanation) and my expectation is just wrong. There’s nothing that could be done about this.
  • The behavior is also surprising to others. It may be a bug. Then I could file a bug and maybe someone could fix that in the future (or provide more insight). As I do not want report a bug that is not a bug I thought that first asking here is the better alternative.

In particular, although I’m very grateful for all suggested workarounds (and I’m using one of them now), I did not expect someone to provide or develop one for my problem (except for the first point above, of course). I would just like to know if I made something obviously stupid (what, given my own incompetence, I consider very likely) or if there is no immediate hope and I have to use some workaround.

#13

Not sure why it happens. Maybe some faulty size/padding metadata in the source object.

A workaround that seems to do the trick is to insert a section, then insert your object into that section.

test2 adjusted.odt (17.4 KB)

Not sure whether that suits your workflow, though. Please post back with more detail if it doesn’t. (According to my reading between the lines, there seems to be more happening to your content than what is said.)

#14

Also, if the object belongs with the leading text, it may be better to have both inside the section, instead of the object alone as I did in the example.

#16

You can achieve a slightly more “convoluted object” by using a frame instead of a section. Frame content is not part of the main content flow the same way that section content is, which may be an advantage in some cases and a drawback in other cases.

#18

Unfortunately, you bump into the bug I describe above: position “Bottom” of paragraph area (both “text” and “entire”) creates a mess. I first noticed it months or years ago with frames and discovered today (but this is not surprising because the same code is used) that it also affects drawing objects.

1 Like

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.