Created attachment 64276 [details]
file used in the picture
Currently LibreOffice allows anchoring graphics to paragraph. This is useful when graphics is about to jump to the next page. On previous page a lot of empty space can stay. In this case the paragraph jumps before the graphics and fills "some" of empty space. But there are cases when there is place for more paragraphs.
See the first picture (paragraphBEFORE.png). When we (at the beginning of the document) add some text (new lines) we get the second picture (paragraphAFTER.png). On first page bellow there is still a lot of free place. Is it possible to adjust that other paragraphs jump to this free place?
This is a must to have feature for technical documents.
Similar problem is seen there: http://listarchives.libreoffice.org/global/users/msg16753.html
Platform (if different from the browser):
Browser: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0.1
Created attachment 64277 [details]
document before inserting new lines
Created attachment 64278 [details]
document after inserting new lines
This is 8 years old issue.
Cited main idea from ticket:
"If the anchor point for the graphic is less than 25% into the page, insert the
graphic in place; otherwise, move the graphic to the next page AND BRING THE
TEXT THAT FOLLOWS THE GRAPHIC FORWARD, SO THAT THERE IS NO BIG GAP OF VERTICAL
WHITE SPACE ON THE CURRENT PAGE".
Current problem can be partially solved with SHIFT+ENTER (creating new lines without creating new paragraphs). So we have then one big paragraph.
But the problem is that in this case it's not possible to make the paragraphs not to split.
Because of that we would need "anchor to multiple paragraphs". See Bug 52274 for wish that pictures don't split paragraphs too.
So just to clarify what is being requested is that you could select many paragraphs and attach an image to all of them and then the system would make some kind of calculation to guess at where you want the image to be? Honestly this does not sound feasible at all. If you attach the image to let's say paragraph 2 and paragraph 3 in your image, then the image just "jumps" around depending on how many spaces there are. It seems like the better solution is just for the user to attach the image to the right paragraph - in this case, it would be paragraph 4 so that the other paragraphs jumps to page 1.
I am marking this as NEEDINFO - please give us a bit more insight of what you are looking for. If it's as I described above, this seems to me to be very difficult and not horribly efficient (because the image would jump around without user moving it depending on . . . well I'm not exactly sure to be honest. I think it's not safe to have a computer guess at what paragraph is most efficient for an image to be attached to.
Workaround - User attaches the image to the page until writing is done, then attach to relevant paragraph once no more writing is needed. This way location of image is preserved and the computer isn't moving the image around between paragraphs.
Once you provide more please set to UNCONFIRMED. Apologies for the long delay
(In reply to comment #5)
> So just to clarify what is being requested is that you could select many
> paragraphs and attach an image to all of them and then the system would make
> some kind of calculation to guess at where you want the image to be?
> Honestly this does not sound feasible at all. If you attach the image to
> let's say paragraph 2 and paragraph 3 in your image, then the image just
> "jumps" around depending on how many spaces there are. It seems like the
> better solution is just for the user to attach the image to the right
> paragraph - in this case, it would be paragraph 4 so that the other
> paragraphs jumps to page 1.
> I am marking this as NEEDINFO - please give us a bit more insight of what
> you are looking for. If it's as I described above, this seems to me to be
> very difficult and not horribly efficient (because the image would jump
> around without user moving it depending on . . . well I'm not exactly sure
> to be honest. I think it's not safe to have a computer guess at what
> paragraph is most efficient for an image to be attached to.
> Workaround - User attaches the image to the page until writing is done, then
> attach to relevant paragraph once no more writing is needed. This way
> location of image is preserved and the computer isn't moving the image
> around between paragraphs.
> Once you provide more please set to UNCONFIRMED. Apologies for the long delay
The first idea was as described by you in the first point. Nevertheless, I agree with you that this workflow is not suitable for WYSIWYG. Figures should not jump around in "undefined" manner when user types.
The main idea was to optimize figure placement (see Latex) but it is hard to achieve it interactively.
Maybe better approach would be to implement a new command (plugin): "Optimize figures placements", which optimizes figures placements in relation to some parameters (e.g. allowed positions of figures). What do you think?
I am non very confident with automatic placement of figures. Indeed when you anchor a figure to a paragraph, it is not only because there is room to place it. It is for good understanding of the text too. For example I prefer to have the figure I refer in a paragraph to on the same page. If needed, I prefer to move the paragraph and the figure instead of anchoring the figure to another paragraph.
Best regards. JBF
What happens in this scenario if the paragraphs that jump to the previous page have objects anchored to them and they are smaller than the first object so they are able to fit on the previous page and also another object that belongs with a paragraph after that can also fit?
This may sound silly: a word processor aids the user in the composition, editing, and formatting of written material. LO Writer is not just for writing, it is an editor too. Work flow should constitute discrete tasks. Wanting as much automation as possible is understandable but sometimes there are tasks that the software handles and other times there are tasks that require the user to make decisions.
Being focused on getting what one is writing to look like the end product while still in the draft stage is not the most productive state of minds. It is best to ensure that one is getting the content that needs to be there first before deciding where and how it should look. That is not to say that one cannot do a little planning before hand with regards to styles and structure.
In other words, you can always edit the document after it has been drafted and place the object to your liking.
Changed to RESOLVED WORKSFORME.
With enhancement requests the bar is set quite low - if we are closing as WFM it should clearly explain why this feature would not help *at all*. If it would help in the slightest, we move to NEW (with the caveat that many enhancement requests are never implemented because no developer is really interested in it). That being said - reading the last comment I'm not entirely convinced that this wouldn't help at all (in other words that it's a completely bizarre/unfeasible request).
@Gordo - can you clarify a bit to explain why this isn't useful at all
(In reply to Joel Madero from comment #9)
> If it would help in the slightest, we move to NEW
And yet there it sat, languishing in limbo for nearly three years. There has been amble opportunity for this to be NEWed.
Ignoring the feasibility of implementation and how/if it would impact other functionality, I admit that I find it difficult to argue that it is not useful based solely on the fact that every request is valid until proven otherwise. What criteria are presently being used to judge usefulness?
Does the proposed functionality:
1. Offer anything beyond what is currently possible? Yes, but the end result is currently possible by the user.
2. Reduce the time or manual effort required to preform a specified task? Not really. It could be argued that the solution costs more than the current workaround. Firstly, the user does not realise that there exists the possibility of extra space at the bottom of the page until it happens. The act of selecting the paragraphs for additional text flow to get things just right is more effort than manually moving the anchor to another paragraph. Secondly, the user selects paragraphs for additional text flow every time they add an object. How many of those objects will ever be in the situation that additional text flow is required? The set-up still costs more than the current workaround.
3. Reduce a repetitive task? No.
4. Have support from many voices from different fields of interest? Silence.
5. Make you go “wow”? My subjective answer is no.
6. Make the product look more attractive to potential users?
7. Make the product look more attractive to potential contributors?
The question is simply whether any user would find it useful and whether it would break any current functionality or fall so far out of the scope of the project that it is INVALID. Again, the bar is very very low for enhancements - we want to encourage creativity, not squash it. The fact that it's gone 3 years without confirmation is more a signal that most people did not understand the request - not that it's not a valid request. You apparently understand it....