This is almost identical to the situation I face when writing a
document with several inserted graphic images (from file).  The images
jump around, land up on top of one another and in general will not
stay where they are placed.  Changes to anchoring have little effect
on this behavior.  I, too, consider this a defect, a bug.

The positioning of graphics is faulty in other cases too. When I have
got text - graphic - text - graphic, so that a automatic pagebreak
would be before the second text, the second graphic jumps onto the
first graphic. I reported it in the SO betatest group. I work with win98.

Regina

I can confirm this issue. I think it's P3 and target OOo 2.0, even
that I'd like to see it fixed in OOo 1.1.1.

It's exactly as Robert describes it, and this is very annoying.

Sorry but indeed, it is not defect!
Just have a look to the icons in the context or within the dialog
about wrapping. You can see, that only the text is mentioned.

Created attachment 7342 [details]
Shows the graphic jump onto another

I have send a file which shows the problem. Description is in the file.  I think it is a 
defect, but it is not due to word wrapping but to the algorithmus for the automatical 
page-break.

I appologize if the description is not accurate, but I, personally,
have been unable to find out why graphics will jump around within a
document or on a page on their own and why they will not stay where
they are put.  Perhaps this should be assigned to a category other
than word wrapping issues, such as the algorithms that supposedly keep
things in their places.

Hi,

I've been thinking about this. It's really a "float placement
algorithm" problem. Clearly, figures don't spontaneously jump about
without some sort of user interaction! The problem is evident While
editing or creating a "real life" document: figures/frames tend to
jump onto one-another because 1) overlaping frames are allowed by OO,
2) Multiple overlapped frames minimises the page space used. The OOo
frame-placement algorithm appears to try to find the most compact
layout for the document. This happens to be with frames overalapped,
even though this is not normally what the user would want.

The best solution, from the user-perspective, is to have an additional
(boolean) frame-option "Exclude Other Frames". This option should be
the default for all frames (since 99% of users will not want their
frames/graphics to overlap). For the few cases where overlapping
frames are required, the option could be switched off for the frames
concerned. Thus, I now think this issue is best treated independently
from text-wrapping.

Note that the "Exclude Other Frames" option would only prevent
overlapping of frames at same level of the document hierarchy.
Obviously, frames *inside* other frames etc. must overlap.

I'll post a couple of documents as examples to try to illustrate the
point.

Bryan

Created attachment 7370 [details]
Illustrating the problem of frame-overlap

I just attached a "real" document to illustrate the problems of
frame-overlap (OK, the graphics are not real. I changed the images to
make the file smaller). Problems with this documents as follows:
- Column 1, page 1 : why does OO leave all that empty space at the
bottom of the column? This should be filled with text
- Column 2, page 1 : Clearly the overlap of the page-wide title-frame
and the first figure is not desirable.
- Column 1, page 2 : More figures overalapping.

Try moving blocks of text around or moving the figures to get an idea
on how frustrating the OO frame-placement is!

Clearly, it is always possible to manually re-arrange the figures into
a nice layout, but OO's default automatic float-placement is poor.
Things would be much better if frames were forbidden from overlapping.

Bryan

Hallo Bryan,

I had a look at FrameOverlapExample. OOo behaves as I would expect 
it. Since the title-frame is anchorded to the page, it is out of normal float and 
therefore should be allowed to be coverd by other frames. (You can use column in 
section rather than in page to avoid this.) Fig1 is correcly placed; I would see it as an 
error if the text of the next paragraph will come before the frame, but I knew some think 
different about this. Fig2 and Fig3 are anchored to the same paragraph. Why should the 
not overlap? You only have to change their position to get them not overlappping. If 
their were anchored to different paragraphs and would overlap, than it would be an 
error as in my attached file.
I agree with you, that a more powerful control of 
overlapping (including both text and frames) would be nice.

I think some of this misses the most frustrating part of this issue.

It seems to be true that the user has to do something for the graphics
to move from where they were placed.  It has only happened to me when
I started editing by moving away from the page.  When I come back to
the page with the graphics, they may overlap or sometimes even jump
from one page to another (most often to a lower-numbered page so that
they now overlap on that page instead of being on separate pages).

A related issue is the mysterious space beneath some graphics even
when all spacing is set to "0".  Sometimes it happens and sometimes it
doesn't, even when the same kind of graphic (such as a .png file) is
inserted.

In other words, the way OOo is currently constructed, it is certainly
a nasty feature that graphics will (1) not stay where they are placed
and (2) sometimes have and sometimes do not have extra space (this is
especially apparent when a graphic is inserted in a frame -- some have
the extra bottom space and others don't, even though both sets of
frames and graphics have identical spacing in the dialogs).

To assert that the incredible jumping graphics are "behaving as
expected" makes as much sense as saying that the words of a document
would be "behaving as expected" if they jumped around the page in an
arbitrary patterns when the user moved back to a previous page.  If
it's a feature, it's a feature that mitigates against using OOo for
any document with many graphics.

I think in this issue some things are mixed.
1. OOo lets free space, if an object (I mean frames, pictures ...) is
placed on the next page or column, because it has not enough room on
the previous. Some people think, that this space should be filled with
the text of the next paragraphs. I do not agree to that. This is
already mentioned in issue 8609 and perhaps should be discussed there.
2. Yet the floating settings of objects apply only to text, not to
other objects. I recommend, that the floating settings should be
altered. I even wish that in general some floating abilities are add,
for example to say a paragraph that no other object may be in the same
line, as it is possible in HTML. This should be discussed in this
issue and it is an enhancement.
3. On some circumstances objects looses there position and even jump
onto another. I think this is a defect and it happens to me too. I
found this already posted in issue 10634 and now attached my file
there. Perhaps you have other examples that show this defect and you
can attach them there too. It seems to me, that the quality team does
not see the problem until now.

I think this last comment is illustrative of the incomprehension I've
seen when I've brought this up in the past.

Regina Henschel writes:
<<1. OOo lets free space, if an object (I mean frames, pictures ...)
is placed on the next page or column, because it has not enough room
on the previous. Some people think, that this space should be filled
with the text of the next paragraphs. I do not agree to that. This is
already mentioned in issue 8609 and perhaps should be discussed  there.>>

This is not in question.  I fully understand that, if a graphic won't
fit on a page or column, it will try to find a place on the next page
or column.  That's understandable and, if we really want the graphic
to fit on that first page, we either need to resize it or make some
other accomodation so it will fit.  Having done that, however, if we
later open the document, we do NOT expect the graphic to have changed
position and now be on top of another graphic on the PREVIOUS page. 
NOR do we expect that most of the graphics would have changed position
from those they once happily occupied.  In short, GRAPHICS SHOULD NOT
CHANGE POSITION FROM ONE VIEWING OF A PAGE TO ANOTHER.  That is, as I
suggested six months ago - a bug.

I find myself completely puzzled by what Regina is referring to when
she says that text has floating settings.  It makes no sense to me. 
Regina, would you care to illustrate what this refers to?


The reference to 10634 seems (?) to be a duplicate of this issue,
although I am not certain.  I have changed anchors to each and every
possible anchor and the arbitrary jumping around of the graphics
continues.  I move up to check on how I have written something and
return to my page only to find the graphic has gone somewhere else --
most often to a previous (not following) page and is often on top of
other graphics.  I get everything set right and close the document. 
When I reopen it, the positioning of the graphics is a surprise --
again, movement is most often to toward the top of the text and on top
of an existin graphic.  In one case, I had five graphics slapped
haphazardly on top of one another.

EXPECTED BEHAVIOR:  Once put, the graphic should stay put.  If
anchored to a paragraph, the graphic would move only if the paragraph
moved.  If anchored to a character, the graphic should follow the
character (if it moves) or jump to the previous character if the
character is deleted.  If anchored to a page, it should stay with the
page.  If anchored to a page (for example) and nothing further is done
with the text, it should not "jump" to a different page or "jump" to a
different location on the page.

Inserted objects and graphics should stay where they are put unless
the USER makes changes.  The PROGRAM shouldn't be putting those
objects in arbitrary places.

Hi Robert,

you wrote: "I find myself completely puzzled by what Regina is
referring to when she says that text has floating settings.  It makes
no sense to me." 
In HTML the CSS properties 'float' and 'clear', which control the
floating, can be applied to all block-elements including paragraphs.
So you can have for example two paragraphs beside a block and the
third paragraph below all, without defining any columns. In OOo this
is only possible, if you define columns in section or table.  For
details on HTML and CSS see www.w3.org
 

Thanks for the info.  I was unaware we were talking about HTML editing
and not Writer.  Now I have an idea what "floating" means.

Now, back to the main issue.  Is anyone aware what causes the inserted
objects to change locations arbitrarily?

There seems to be a number of frame/graphic positioning issues under
discussion here, so I've filed an "enhancement proposal" for the
addition of the "exclude other frames" Frame-option (issue #16803).
This would, I feel, fix a lot of the unpredictability in moving
paragraph-anchored frames around, by preventing the
"jump-onto-eachother" effect.

Bryan

Hello Oliver, this issue describes a problem, which fits to the enhancement area
for fly frames in Writer (adding missing alignment, anchoring and position modes
to fly frames). Can we close this issue now? 

I see the many complains about the positioning and overlapping of objects in the
Writer, which are made here. Several issues are mixed up here, as stated by regina.
Thus, I will go back to the 'defect' described by the submitter bryancole:
The wrapping mode of an object only influences the wrapping of the text around
this object and has *no* influence to the positions of other objects, as stated
by hi. There is no planning for OOo 2.0 yet to introduce an option to control
the overlapping of objects. Thus, the given intepretation of regina for the
document from byrancole is correct, except that also objects anchored at
different paragraphs can overlap.

The other complains - except the one given by the document from regina, which is
already handled in issue #10634# - aren't very specific and aren't reproducable
because of missing documents. I propose to submit new issues with documents for
these.

OD->AMA:
Please let's discuss, if we want to introduce an option to control the
overlapping of objects for OpenOffice.org 2.0

For OOo 2.0 we will not implement a new behaviour.
For OOo later we are planning to have a checkbox "Allow overlap" for objects. If
it's disabled the objects shouldn't overlap each other. But they could be still
side by side even their attribute is "No wrap".

*** Issue 46365 has been marked as a duplicate of this issue. ***

POTENTIAL (TEMPORARY) WORKAROUND USING STYLES

It's hard to believe this is still unresolved 6 years after bryancole's first
post, but I just ran into this problem in my rather large document (40+ pages).
It's happening to the frames that OOO 3.1.1 creates when you add a caption to a
picture. 

I think I may have a potential **workaround**: Create a paragraph style called
"Figure" or something like that and in its "Test Flow" options, turn off the
flow controls ("Orphan Control" and "Widow Control"). Apply that style to every
Frame or Figure (if your figure is inside a frame due to captioning, you need
only apply it to the frame). The Styles drop-down menu tends to disappear when
you select a frame, so make sure to open the "Styles and Formatting" box prior
to selecting the frame. It's a pain-in-the-neck way of doing it, but I'm pretty
sure it works.

CORRECTION: WORKAROUND DOESN'T WORK

Sorry folks, the workaround I posted yesterday does not work. I'm not sure why
it seemed to at the time, but I re-opened the document to work on it some more
and my two frames were lovingly on top of each other again despite my disapproval.

It seems that the paragraph formats that I was trying to apply to frames don't
apply at all and don't have any effect. Sorry if I misled anyone. It looks like
the only way to get this to work is to write the whole document and fiddle with
the frames afterward to make sure they fit and don't overlap.