Apache OpenOffice (AOO) Bugzilla – Issue 8609
Blank space between anchorpoint and frame
Last modified: 2013-02-07 22:42:14 UTC
i had posted on problems with anchors in an earlier bug (http://www.openoffice.org/issues/show_bug.cgi?id=6515) 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. INTRO 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 pages 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 window. 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 time. 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 OR 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.
Created attachment 3292 [details] example writer file demonstrating problems with anchors
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.
> 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.
next bug in series (BUG TWO) is at issue 8648 (http://www.openoffice.org/issues/show_bug.cgi?id=8648).
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.
Thanks for the explaination Andreas. Works for me.
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.
*** Issue 4990 has been marked as a duplicate of this issue. ***
*** Issue 8648 has been marked as a duplicate of this issue. ***
Joost->AMA: I know that "Bug 4" has been fixed within the development tree.
I changed the Summary to have the appropriate description of the remeining enhancment. Reassigned to Bettina.
OpenOffice.org 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: http://download.openoffice.org/index.html or consider trying the new OOo 3 BETA (still in testing): http://download.openoffice.org/3.0beta/ 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: http://www.openoffice.org/issues/query.cgi Many thanks, Andrew Cleaning-up and Closing old Issues as part of: ~ The Grand Bug Squash, pre v3 ~ http://marketing.openoffice.org/3.0/announcementbeta.html
To grep the issues easier via "requirements" I put the issues currently lying on my owner to the owner "requirements".