Issue 10634

Summary: Graphics and other objects don't stick to their paragraphs
Product: Writer Reporter: Unknown <non-migrated>
Component: codeAssignee: AOO issues mailing list <issues>
Status: ACCEPTED --- QA Contact:
Severity: Trivial    
Priority: P4 CC: issues, oooqa, rb.henschel
Version: OOo 1.0.1Keywords: oooqa
Target Milestone: ---   
Hardware: PC   
OS: Windows 2000   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
when deleting manual page-break grafik jumps onto another
example document with the next workaround applied none

Description Unknown 2003-01-13 19:22:18 UTC
Inserting graphics or other objects gives you the possibility to choose the way
the position of the object is defined. When assigning an image to a paragraph,
the image tends to go away and stay at a random place anywhere else in the
document, even if you set it to a fixed position and size.
Comment 1 prgmgr 2003-06-14 16:24:33 UTC
Thank you for using and supporting OOo.

Try some of the options found when right clicking the graphic and
choosing the Graphics menu option.  You may want to change how the
graphic is anchored to the text.

Also see issue 8609.
Comment 2 Regina Henschel 2003-07-06 12:56:40 UTC
Created attachment 7439 [details]
when deleting manual page-break grafik jumps onto another
Comment 3 Regina Henschel 2003-07-06 13:00:23 UTC
I can confirm this behavior for the german version on Win98. Try the
attached file and delete the manual page-break. Then the graphics are
jumping onto another, although they are anchored to different
paragraphs. This happens to other users too, see issue 16292
Comment 4 mci 2003-09-09 08:32:23 UTC
@od:  Hi od, I think it's the same thing like the two other Issues you 
      got from me...

reassigned to
Comment 5 Oliver-Rainer Wittmann 2003-09-09 09:34:35 UTC
OD (09.09.2003):
The described behaviour is a little bit tricky:
Without the manual page break the paragraph "Second important..."
starts at the page with the paragraph "First important...". But, it's
content is completely moved to the next page, because of the graphic
anchored at the paragraph "First important...". Thus, the paragraph
"Second important..." internally is splitted into two parts. For
objects, which are anchored to paragraph and are vertical positioned
'top', 'center' or 'bottom', like the graphic at the paragraph "Second
important...", takes the first part of a paragraph to determine the
'top', 'center' or 'bottom'. Conclusion, the graphic at paragraph
"Second important..." is placed at the previous page. This is the
current implementation.
But I agree, that it is a defect, that, if a paragraph is splitted,
the first part is taken for vertical object positions 'top', 'center'
or 'bottom', if the first part contains no content. This should have
to be changed. The detection of such an situation isn't very easy.
E.g., Think of a paragraph with 10 lines and an object anchored to
this paragraph positioned at the top of the paragraph, 3 lines high,
with wrapping mode 'no wrap'. Now the paragraph moves to the end of a
page and a height of only three lines are left. In this situation the
paragraph is also splitted into two parts, the first part will be
empty and the object will be *correctly* positioned at the top of the
first, empty part.
Hopefully, this helps to understand the current behaviour. I will try
to implement the above given proposed fix in the next version - stay
Meanwhile, I have got a workaround for your specific document: delete
the manual page break and change the anchor type from 'to paragraph'
to 'to character'. Then the graphic will be on position you excepted.
Comment 6 mci 2003-09-09 10:02:39 UTC
Comment 7 Regina Henschel 2003-09-09 13:46:12 UTC
No the workaround doesn't work. I changed the anchor type from 'to
paragaph' to 'to character' and delete the manual page break. It seems
to be correct. I controlled that the position is still vertical
'bottom to paragraph text area'. Then I delete some lines in the blind
text, so that the paragraph 'second important' will fit on the first page.
I expect, that the graphic will stay on the second page, because it
has 'bottom to paragraph text area'.
But the graphic jumps to the first page and the wrap is turned to
The algorithm for calculating position of graphics in case of page
break seems to be very buggy. That thing, that a wrap is automatically
changed, must not happen.
Comment 8 Oliver-Rainer Wittmann 2003-09-09 15:12:24 UTC
OD->Regina (09.09.2003):
Thanks for your further investigation.
But, as I mentioned above, an object, which is vertical positioned
'top', 'center' or 'bottom', takes the first part of the paragraph to
determine 'top', 'center' or 'bottom' position. If such an object is
anchor to character, the part the character is in is taken. In your
given document with the workaround, this is the first character of the
The change of the wrap mode, indicates that an unsolvable situation
occurs. In your given example I think, (1) the object is placed at the
bottom of the first part of the paragraph. Because of the given wrap
mode, (2) the complete text of the paragraph is moved to second page.
Thus, (3) the to character anchored object moves also the second page,
because it wants to stay on the same page, where its anchor character
is. Now on the previous page is space left for the paragraph text and
(4) the text flows back to the previous page. (5) Now, the object
again will follow and we start again with (1) and so on. 
To break such a loop, we decided to change the wrap mode.
I will attach your document, in which the object is anchored to the
last character of the paragraph and is vertical positioned 'from
bottom -0,4cm to character'. Hopefully, this document will be the
final workaround. Important note: Due to a defect, this specific
position can't be set using the frame position dialog (negative values
are suppress), but by moving the object with the mouse.
Comment 9 Oliver-Rainer Wittmann 2003-09-09 15:13:26 UTC
Created attachment 9129 [details]
example document with the next workaround applied
Comment 10 Regina Henschel 2003-09-09 19:40:16 UTC
I tried your document:
(1) I activate the Graphic via navigtor, not touching it with the
mouse. I open the graphic-menue via "Format -> Graphics", again not
touching the graphic. I do nothing in that menue but close by clicking
OK. The graphic moves again. Now it is before the last line of paragraph.
(2) New test on original file. Once again deleting lines in the blind
text so that the paragraph "second important..." comes up. I get two!
lines of the paragraph on the first page, on the second page the
graphic followed by the third line, an the paragraph looses its Orphan
and Widow control.
You see, no solution. But please don't search another workaround. My
workaround and that of much others is, not to try do place a graphic
during writing the document, but only after all other things are
completed, control it and print it immediately and hope that there is
no need to change text.

My idea is, that in case of position 'bottom of paragraph text area'
the graphic should stay beneath the last text line on all
circumstances. Than you will get no loops at all, and that is the way
I understand 'bottom of paragraph text area'. Calculating its position
can than use the position of the last text line. You should also leave
the space at the end of the page empty, if the graphic moves to the
next page. I knew, others like it to be filled, but for that purpose
an additional position-specification should be generated.
Comment 11 rblackeagle 2003-09-10 01:19:53 UTC
My experience with Linux using the RC's has been that the solution you
suggest doesn't always work.  I've had the graphics move when I tried
to print as well as when I moved to another page and back again.

I believe this is just another version of the "incredibly jumping
graphics" that has been reported for a few years.  It is my
understanding that at least one developer is looking at it, but I
can't recall the issue no.
Comment 12 Oliver-Rainer Wittmann 2003-09-10 12:31:40 UTC
Comment 13 ulf.stroehler 2003-10-02 17:17:37 UTC
According to the roadmap
( this issue was retargeted to
OOo Later.
Comment 14 Oliver-Rainer Wittmann 2003-12-01 11:40:49 UTC
Comment 15 Marcus 2017-05-20 11:24:14 UTC
Reset assigne to the default "".
Comment 16 Marcus 2017-05-20 11:26:09 UTC
Reset assigne to the default "".