If Images or Frames (probably other Objects too) are locked to a page and there is a page (or pagebreak) is added before that page the object was first located on, the object does not stay with the page, e.g. it does not move with it's page. Example: 3-page document, on page 2 and image or frame is positioned and locked to the page. Now inserting a page break on page 1 (actually adding a new page here) moves the text of the previous page 2 to page 3 (correct), but the object still stays on page 2 (and it should have moved to page 3 also). Earlier in Word there has been two options for this: - lock to page (moves with page) - lock to absolute page (does not move, what we have in 4.4.0.3 now)
Adjusted title, set to enhancement. Win 7 Pro 64-bit, LibO Version: 4.4.0.3 Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Locale: fi_FI
(In reply to Stefan from comment #0) > first located on, the object does not stay with the page, e.g. it does not > move with it's page. If "it's page" is the text it belongs too, anchoring to paragraph is more logic in general. Does it happen often, Stefan, that you need the requested behavior?
Hello Cor Nouws, locking something to paragraphs is good for many things, and I use it daily, of course. But for certain types of manuals and instruction sheets I prefer locking object to the page, as there are more images and arrows and such and only few text lines at all. I wondered about the internal logic - locking somthing to page 3 and then inserting a new page before should keep the object with the page it was originally anchored to. It drives me silly to having to move those ibject manually ;) Adding the suggested anchor could: + add a feature that was available in Word for decades + allow to import/convert Word-files with that type of anchor correctly (and thus encurage swapping to Libreoffice :) + make things more logically (at least IMHO)
*** Bug 117329 has been marked as a duplicate of this bug. ***
[Copying a comment from Bug 117329] ------ Just to make things clear, a quick and oversimplified review of what LaTeX does by default (users can change those settings) with its "floats," either figure or table, always considering the insertion point as reference: 1. If there is space, figure is moved to the top of the page text area 2. If there is no space on top, figure is moved to the bottom of the text area 3. If still there is no place, figure is moved to the following page 4. If *still* there is no place, figure gets its own page, as close as possible to the insertion point The probability of getting two pictures superpose is exactly zero in LaTeX, and they will never cover footnotes. All this is performed automatically by LaTeX every time the document is compiled. In Writer you can set the frame positioning to be on top or bottom of the text area, even in the frame style, but there is a high risk of two pictures going one on top of the other or accidentally covering footnotes, so you need to do the positioning by hand for each frame, and then move anchor points of those frames to avoid "holes" at the end of page when the paragraph to which the frame is anchored moves to the next page.
*** Bug 119024 has been marked as a duplicate of this bug. ***
(In reply to RGB from comment #5) > [Copying a comment from Bug 117329] > > ------ > > Just to make things clear, a quick and oversimplified review of what LaTeX > does by default (users can change those settings) with its "floats," either > figure or table, always considering the insertion point as reference: > > 1. If there is space, figure is moved to the top of the page text area > > 2. If there is no space on top, figure is moved to the bottom of the text > area > > 3. If still there is no place, figure is moved to the following page > > 4. If *still* there is no place, figure gets its own page, as close as > possible to the insertion point > > The probability of getting two pictures superpose is exactly zero in LaTeX, > and they will never cover footnotes. > > All this is performed automatically by LaTeX every time the document is > compiled. > > In Writer you can set the frame positioning to be on top or bottom of the > text area, even in the frame style, but there is a high risk of two pictures > going one on top of the other or accidentally covering footnotes, so you > need to do the positioning by hand for each frame, and then move anchor > points of those frames to avoid "holes" at the end of page when the > paragraph to which the frame is anchored moves to the next page. Is there a way to crow funding this option? I mean, I really want this to be implemented and for sure many other people will want. How can we 'sponsor' this incoming feature?
(In reply to Jose from comment #7) > Is there a way to crow funding this option? I mean, I really want this to be > implemented and for sure many other people will want. How can we 'sponsor' > this incoming feature? Freedomsponsors has been used in the past: https://freedomsponsors.org/project/149/LibreOffice#/LibreOffice The site is not very actively maintained, though. Apparently people have also used Bountysource to place bounties: https://www.bountysource.com/teams/libreoffice Bounties defined by users are difficult, however. How do you know the scope of the problem? Is $100 or $1000 enough?
*** Bug 50379 has been marked as a duplicate of this bug. ***
1. There's no "to page" anchor in Word. 2. Anchor "to page" is "to specific physical page number", and it should not move to another physical page number. If an object should move with some neighbour document content, it should be anchored not to page, but to the content.
There are several common triggers which can cause page-anchored images to slip out of position: adjusting line or paragraph spacing, changing page dimensions etc. So, IMV, this would be a very useful enhancement.
How is this "NEW"? Does *anybody* here who imagine "this" would be "a very useful enhancement" realize what "this" might be? How could something be anchored to something that does not exist? There are no pages in Writer document. At all! Pages are only a viewing artifact, created on demand. "To page" anchoring means actually "to page number", where number is "Nth page of all pages", not "page showing N in its footer". If you need something that can move, you need to anchor that to something that is movable. That is content. You have plenty of content anchors - to character, as character, to paragraph, to frame. This is not even WONTFIX: that would mean "this is acknowledged, but needs needs unreasonable amount of work" or something like that. This one is "INVALID", because asks for something that simply cannot exist.
(In reply to Mike Kaganski from comment #12) > How is this "NEW"? Does *anybody* here who imagine "this" would be "a very > useful enhancement" realize what "this" might be? How could something be > anchored to something that does not exist? There are no pages in Writer > document. At all! Pages are only a viewing artifact, created on demand. "To > page" anchoring means actually "to page number", where number is "Nth page > of all pages", not "page showing N in its footer". It is NEW because in 2015 I was still young and naive.
FTR: https://wiki.documentfoundation.org/Faq/Writer/AnchoringAndPositioning may be helpful to allow users to choose the correct anchoring and positioning. I believe that using wrong "to page" anchoring, when user actually wants "to paragraph" anchoring + "to page" positioning, is the reason for filing proposals like this.
I don't agree with this too developer-centric approach. From user's point of view, this requirement is valid: I want to anchor an object such a way that it moves together with some page content while it stays at the same position relatively to the page (we can call it whatever, not "anchor to page and move"). Maybe now this can be achieved somehow, I was interested in it long time ago when it was not possible (and I was using my extension to workaround it).
(In reply to Stanislav Horacek from comment #15) Please look at comment 14. It is exactly the case of user error, using wrong feature, not knowing what to use correctly. I even wrote: > I believe that using wrong "to page" anchoring, when user > actually wants "to paragraph" anchoring + "to page" positioning, is the > reason for filing proposals like this. You immediately write: > I want to anchor an object such a way that > it moves together with some page content while it stays at the same position > relatively to the page (we can call it whatever, not "anchor to page and > move"). Isn't that exactly the same?
OK, I see your point - thanks for that! I admit I've never considered that anchoring to a floating paragraph/character could actually mean fixing the position within the page. (I think that the most intuitive mental model is "fixing image within the page -> anchor it to the page" and "moving image with the paragraph -> anchor it to the paragraph".) However, when such an image (anchored to the paragraph and with position relative to the page) is moved manually, then the position is changed to relative to the paragraph - which would be a stopper if manual adjusting of position is needed. But this is another issue...
(In reply to Stanislav Horacek from comment #17) > However, when such an image (anchored to the paragraph and with position > relative to the page) is moved manually, then the position is changed to > relative to the paragraph - which would be a stopper if manual adjusting of > position is needed. But this is another issue... ... to which I wholeheartedly agree - IMO, manual dragging should not change the type of positioning, just the position itself. We also need a drag mode that only moves anchor without moving object, and a mode that only moves object, without moving anchor ...
(In reply to Stanislav Horacek from comment #17) > (I think that the most intuitive mental model is "fixing image within the > page -> anchor it to the page" and "moving image with the paragraph -> > anchor it to the paragraph".) Note that you can't avoid making some kind of a link to *content* when you want your data to move *with content*. So how to call that link? We call that rather flexible link "anchoring" (anchored ship is not immovable). Note how you use term "position" yourself, when describe that the object needs to stay on the same place on page: (from comment #15) > I want to anchor an object such a way that it moves together with some > page content while it stays at the same *position* relatively to the page And we call that exactly that way: position, which is different from anchor. So it's just a learning curve - and a matter of asking a "how do I" question, before filing a bug ;-P
(In reply to Stanislav Horacek from comment #17) > However, when such an image (anchored to the paragraph and with position > relative to the page) is moved manually, then the position is changed to > relative to the paragraph - which would be a stopper if manual adjusting of > position is needed. But this is another issue... I filed bug 141160 for that.
*** Bug 54292 has been marked as a duplicate of this bug. ***
Hi Mike, others (In reply to Mike Kaganski from comment #12) > If you need something that can move, you need to anchor that to something > that is movable. That is content. You have plenty of content anchors - to > character, as character, to paragraph, to frame. I fully agree with this point and support the removal of the "to page" option from the contextual menu and toolbar. The option remains available via the properties and that's fine. However, unless I'm mistaken, this change to the interface is not in the release notes. The mention could also refer to the very useful FAQ: https://wiki.documentfoundation.org/Faq/Writer/AnchoringAndPositioning Best regards
(In reply to pierre-yves samyn from comment #22) Ref: bug 140702.