Issue 8609 - Blank space between anchorpoint and frame
Summary: Blank space between anchorpoint and frame
Alias: None
Product: Writer
Classification: Application
Component: ui (show other issues)
Version: OOo 1.0.1
Hardware: PC Linux, all
: P3 Trivial with 1 vote (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: oooqa
: 4990 (view as issue list)
Depends on:
Reported: 2002-10-22 19:31 UTC by Unknown
Modified: 2013-02-07 22:42 UTC (History)
4 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

example writer file demonstrating problems with anchors (114.62 KB, application/octet-stream)
2002-10-22 19:35 UTC, Unknown
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Unknown 2002-10-22 19:31:13 UTC
i had posted on problems with anchors in an earlier bug
( but i think although i
was extremely frustrated (enough to go the point of filing an issue), i still
was way too ambiguous to be helpful, and the bug got invalidated. it was
suggested that i post to the users mailing list.

since then, i have posted a similar message on problems with anchors to the
users mailing list (on 10/18/2002, under "[users] problems with anchors:
HELP!!!") but did not (at least as of 10/22) get a single response. so i am
posting here.

in total, i have spent several days either trying to work around this problem,
or to figure it out and document it.  i hope the post is helpful.


basically, i am trying to get OOo to act like LaTeX does with "figure floats":
the figure will be automatically placed (in the final document) as close to the
"anchor point" (place in original text document) as possible. if the latex
compiler figures out that it must move the figure to the next page, then the
resulting blank space (at end of first page) is *filled* with succeeding
paragraphs by moving them up in front of the graphic appearing at top of page two.

OOo does NOT do this (except only fleetingly -- see below). instead, OOo leaves
a big blank space after the anchored paragraph at end of first page. there are 3
other problems/bugs which, in combination with the first bug, can make it
extremely frustrating for a user.  furthermore, these bugs are tedious to
isolate and document. however, it is worth the effort because of this high level
of frustration.

bugs like these can be the the death-knell of a user confidence in OOo. in my
case, i need to do a dissertation. i was using latex, but wanted to use OOo
because it really is (potentially) highly superior in some ways, and yet still
implements the basic IDEA of latex (by implementing 'styles').

i also had high hopes for the future of OOo: if someday, OOo/SO made a deal with
Adobe for a PDF bridge, i might be able to someday create a *structured* PDF
document (complete with bookmarks and hyperlinks preserved).

now, i realize, unless some fixes are implemented rather quickly, chances are
slim that i will be able to use OOo for my dissertation. i am submitting these
bugs, however, in the hopes that fixing them will remove one more stumbling
block to users wanting to use OOo in the future.

the documentation on anchors also needs some fleshing out. even little things
like: "i see an anchorpoint between paragraph 5 and 6: does that mean it is
anchored to paragraph 5? or to 6?" would be really helpful to the user. i
suppose i should post to the docs group, too... *sigh*.. :) :)

the bugs are below. to follow them, open up the attachment
(anchor_bug_example.sxw) and follow the directions. it's probably not a perfect
description of the problems, but hopefully it gets you into the ball-park close
enough to be helpful.

finally, thanks to the OOo team for all your hard work.


BUG ONE: blank space between anchorpoint and frame itself at ends of

step 1: (done already, in document "anchor_bug_example.sxw")

suppose i have a graphic in a frame. frame is set for "No Wrap", and
is anchored to paragraph 6. graphic is 4" high and 5.2" wide. (i am
working with a US Letter formatted page.)

now if the anchorpoint paragraph ends less than 4" from the bottom of
the page, then OOo will shift the graphic frame itself to the second
page. all this is *fine*, so far.

BUT, the problem is that now, OOo leaves the whole rest of the first
page, *after* the anchorpoint (paragraph 6), *blank*!

that is, what it *should* (IMHO) do (and what LaTeX does) is move text
from paragraph 7 UP from page 2, to fill in the less-than-4"-of-space
after paragraph 6 at the bottom of page 1, so that there isn't any
blank space at the end of page 1.


BUG TWO: any filled-in space is forgotten when document re-opened

step 2: now, with your mouse, left-click on the graphic frame
appearing at top of page 2. graphic frame is now selected and anchor
point also appears at top of paragraph 6 on page 1.

IMPORTANT: make sure you can see paragraphs 5 and 6 both in your

now with your mouse, drag the anchor-point icon to paragraph 5 (one
paragraph earlier). now notice that OOo *does* fill in the blank space
at end of page 1 with subsequent paragraphs 6, 7, and 8, even though
the graphic still appears at top of page 2.

this is EXACTLY the behavior i am intending. unfortunately, :( :( it is
only fleeting:

step 3: save document. close and reopen document. notice that
paragraphs 6, 7, and 8 have now moved back down to page two. OOo
forgot the fill-in that it did before saving. :( the blank space has
returned. :(


BUG THREE: view does not auto-scroll while dragging anchor-point icon

step 3: now, suppose you want to get the anchor point back down to
paragraph 6 again, from para. 5, where it is now. how to do this?

select frame again so anchorpoint icon appears. now, scroll back up so
you can see the anchor point icon which is showing at beginning of
para. 5. THIS IS IMPORTANT: be sure you scroll up far enough so
that OOo's window no longer shows the graphic frame itself. that is,
you cannot see page 2. this represents the case where the user's
monitor -- at current zoom value -- is too small to fit in both the
anchorpoint, the blank space, the new page and the graphic all at same

step 4: now try to drag the anchor point icon down to paragraph 6 on
page 2. it is impossible, because in order to drag it down to
paragraph 6, you have to get to page 2, but page 2 is beyond the
visible window.

it's not unreasonable for the user to expect OOo to "auto-scroll" the
view down to page 2, in order to move the anchorpoint icon down
there. however, this does not happen, and the view does not move.


BUG FOUR: anchorpoint icon lost while dragging beyond page

furthermore, dragging the anchorpoint icon above or below the limits
of the window causes the user to lose control of the anchorpoint icon:
even while mouse left-button is still pressed down, the anchorpoint
icon no longer moves: moving beyond the borders of the view has
severed the connection to the anchorpoint icon.

fortunately, i found two workarounds for BUGS THREE and FOUR:

1) reduce zoom to a point where you *can* see the anchorpoint and
frame both.

step 5: reduce zoom to "Entire Page". (View | Zoom | Entire Page).

now you can move anchor points around, but again, only within the
limits of the view


2) drag the graphic frame itself instead of the anchorpoint.
anchorpoint will follow, one paragraph at a time, EVEN beyond limits
of current view (page will auto-scroll, as expected).

IMHO, however, even with these 2 workarounds, this still represents a
bug (or at least highly undesirable behavior for the user): dragging
an anchorpoint should have the same amount of flexibility as dragging
the frame itself: if auto-scroll works for the frame, it should work
for the anchorpoint icon, as well.
Comment 1 Unknown 2002-10-22 19:35:55 UTC
Created attachment 3292 [details]
example writer file demonstrating problems with anchors
Comment 2 prgmgr 2002-10-23 03:07:09 UTC
Thank you for using and supporting OOo.

Jeff, one problem per issue please.

Please open new issue for the last 3 bugs you list in this issue.

Bug One:

I can duplicate this issue with your document.

However, if you change the anchor point to "To Character" the text 
wraps as you want it to.

Comment 3 Unknown 2002-10-23 14:48:51 UTC
> Please open new issue for the last 3 bugs you list in this issue.

okay, i will post the others separately.

> Bug One:
> I can duplicate this issue with your document.

okay, excellent, thanks.
> However, if you change the anchor point to "To Character" the text 
> wraps as you want it to.

i get this behavior briefly, but -- just as mentioned happens in
anchor-to-paragraph mode -- this lasts only fleetingly. if i save,
close, re-open, there is still a blank space at bottom of page.
Comment 4 Unknown 2002-10-23 15:27:16 UTC
next bug in series (BUG TWO) is at issue 8648

Comment 5 andreas.martens 2002-11-07 17:47:51 UTC
AMA: "BUG ONE" This behaviour is a feature. There's extra code
implemented to assure that paragraph "7" of your example doesn't not
change the page. If a fly frame doesn't find the space on the same
page like his anchor and has to move to the next page, it doesn't
allow any following paragraph to pass the fly frame. AFAIK the idea
behind this was to make visible the relation between the fly and its
anchor. If you want the paragraph "7" to pass the fly frame, you can
change the anchor from paragraph "6" to "7". I think that your wished
behaviour would be okay, too. But if we want to be compatible we
should not change this. I prefer a choosable option for the user. So
for me this is not a bug, it's a feature enhancement.
Comment 6 prgmgr 2002-11-11 23:28:12 UTC
Thanks for the explaination Andreas.

Works for me.
Comment 7 Unknown 2002-11-14 21:47:21 UTC
yes, thanks for the explanation andreas.

however, this does not work for me.

AFAIK, the current implementation of "anchor" is "meaningless". what
if paragraph 6 *refers* to the fly frame and paragraph 7 does not?

what if every time i add new text to the document? with the current
implementation, i will have to manually go and "re-typeset" the
document each time i add new text: i will have to manually check all
the pages of the document by eye to see that a fly frame has not been
pushed onto the next page, and if so, "re-anchor" it.

this completely loses the meaning of "anchor" for me.

thank you for re-classifying it as an enhancement and keeping it
alive. it really is a PITA.
Comment 8 prgmgr 2002-11-29 02:44:36 UTC
*** Issue 4990 has been marked as a duplicate of this issue. ***
Comment 9 prgmgr 2002-12-01 00:07:32 UTC
*** Issue 8648 has been marked as a duplicate of this issue. ***
Comment 10 Joost Andrae 2002-12-01 13:09:15 UTC
Joost->AMA: I know that "Bug 4" has been fixed within the development
Comment 11 stefan.baltzer 2003-01-06 17:16:51 UTC
I changed the Summary to have the appropriate description of the
remeining enhancment.

Reassigned to Bettina.
Comment 12 ace_dent 2008-05-16 02:38:02 UTC Issue Tracker - Feedback Request.

The Issue you raised has the status 'New' pending further action, but has not
been updated within the last 4 years. Please consider re-testing with one of the
latest versions of OOo, as the problem(s) may have already been addressed.
Either use the recent stable version:
or consider trying the new OOo 3 BETA (still in testing):
Please report back the outcome so this Issue may be Closed or Progressed as
necessary - otherwise it may be Resolved as Invalid in the future. You may also
wish to search for (and note) any duplicates of this Issue that may have
advanced further by checking the Issue Tracker:
Many thanks,
Cleaning-up and Closing old Issues as part of:
~ The Grand Bug Squash, pre v3 ~
Comment 13 bettina.haberer 2010-05-21 15:04:58 UTC
To grep the issues easier via "requirements" I put the issues currently lying on
my owner to the owner "requirements".