Graphics do not reliably stay where they are positioned. This has been a problem faced by power users ever since OpenOffice was first officially released.
This article summarizes the problems, possible contributing problems, and workarounds:
Settings that may contribute to the problem:
1.) low default settings for general memory.
2.) default anchor of To Paragraph, rather than As Character.
3.) Follow text flow option is turned off by default.
Other problems may exist in Frames.
A workaround is to place a picture in a table, rather than a frame, but this solution limits options.
Leaders in ODF Authors, including Jean Hollis Weber, can confirm the problems and might have ideas about how to solve them.
thanks for writing, I'm sorry to say however, that this report is not going to help much.
There can be done a lot with types of anchoring and wrapping.
So ideally this report should split up in reports for specific situations with test documents and description.
As this is, no developer is able to use it :(
(Apart from that, I do not recognise it. The only situations that I recognise as possibly being problematic, is with a picture close to the bottom of a page, when anchored at the paragraph, which is what I mostly use. But hard to make a reliable test.)
No doubt splitting up the report into separate incidents may sound sensible from your perspective. However, it is hard to think of a situation in which graphics do not change position: when you open a picture, when you copy and paste one, when you resize one -- the list goes on and on, so what you are really asking is to have a couple of dozen almost identical bugs reported. This task would be so time-consuming that it probably explains why nothing has been done about the situation.
Furthermore, it seems a waste of time to deal with the problem incident by incident. The reasonable inference is that how frames and pictures are handled in general needs a serious examination, and really it is this that I am requesting.
As for you not recognizing the problem, try working with a 30 page document with 20-30 graphics of the sort produced regularly by ODF Authors. Try editing the graphics in every way that you can think of, and you should have no trouble seeing problems.
If you have any interest, I should be able to get some power users to mention their problems. However, my time is extremely limited, and I am not going to undertake such a campaign unless it is useful.
Would you please reconsider your response?
(In reply to comment #2)
> Would you please reconsider your response?
Sorry Bruce, I'm afraid not.
Each existing separate issues needs separate attention. Some may already be reported.
Thus it helps developers to have separate descriptive issues. That is what bugzilla is for (if I'm well informed ;) )
"Graphics do not reliably stay where they are positioned.": that is not true for me. When a picture moved from there to there, I always found the reason in the values of the numerous parameters that control the automatic positioning of the objects in the page.
Without a test document, a clear step by step scenario, a description of the current behavior and a description of what is expected, nothing efficient can be done with this bug report.
So I am tempted to close this bug report as INVALID.
Best regards. JBF
Dear Bug Submitter,
This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.
For more information about our NEEDINFO policy please read the wiki located here:
If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!
Message generated on: 2015-02-18
let's close this one for now. Sorry. Improvements may still be possible, but as explained, that needs different reports.
I really do pity that that this described bug is not solved after so many years. By writing this, I hope it helps getting the attention it needs.
This text describes a bug in LibreOffice Writer (and OpenOffice), concerning stopping re-paginating before a proper - intended - layout is generated.
This bug concerns all users. More specific, it concerns all users that write longer documents with objects like images where text flow is not set to "no wrap".
As suggested, a general accepted work around is to omit text flowing around objects. This can be achieved by anchoring objects "as character" while setting wrapping to "no wrap". This way very large documents can be generated, such as the official LibreOffice documentation.
This solution has three major drawbacks: First, it is impossible to optimize layouts, create richer and more reader friendly layouts. Second, because of the introduced white spaces left and or right from the object, it costs a lot more paper when printing documents with this work around. Third, settings like anchoring as character and no wrapping are not default settings, making users run into problems unexpected, without them having a clue why their document is screwed up.
When normal documents with objects grow in time, there is a point where the background re-paginating process stops unexpected without finishing rearranging the layout. At this point, Tools > Update... doesn't work, while the menu pull down item remains visible, suggesting an unfinished re-paginating process. When the document is saved, closed and opened, the layout is properly restored in most cases. However, when the document grows further, there is a point in time where the layout of the document is permanently broken. Without the knowledge of the workarounds - and even with this knowledge - it chases power users away from LibreOffice.
Typical symptoms of this bug are initial well re-paginated pages, followed by blanc pages and or blanc parts of pages.
This bug is easy to reproduce, simply by adding text and objects in a default way to a default document.
There seem to be much noise around this subject. One of them is the use of too large bitmap objects. Another one that may be, or not, is this one: media.vanderworp.org/.dot/.lo/test_s03e24.odt. This may be related, I don't know. Main thing is that the focus should be on re-paginating of larger documents. A small twenty page text-document with objects in the form of complete empty frames is enough to illustrate the problem. For example, if a TOC is added at page 1 and two heading levels are used, then editing and updating the TOC, toggling between 1 and 2 levels will let re-paginating go south.
In large documents, such as instruction manuals or educational works, like the official LibreOffice manuals , it is highly desirable that objects, such as pictures and quotes, are an integrated part of the text components. This bug makes that integration impossible.
I have some test documents that illustrate the problems. media.vanderworp.org/.dot/.lo/test_s02e15.odt is an example for creating re-paginating errors. If I can be of further assistance, let me know. On the global users mailing list there are multiple threads about the subject.
Hi Wiebe, Bruce,
for what it's worth: some weeks ago I've done the suggestion at the design team:
"idea for nice UX-job: handling of wrapping of images/object in Writer: easy or/preferred use; competitive analysis; compatibility.."
That may lead to the information needed to make choices.
For the time being, I would set to NeedInfo.
With due respect to you guys, I seriously cannot expect that in the current state a developer would have a clear idea of what to do.
Hi Wiebe, all
let me start to stress that input is appreciated. Serious.
But please realize that we handle bugs in limited voluntary spare time.
Then it is contra productive when descriptions are too long. Of course problems are important, many people and examples exits etc etc.
But I have to read 500+ words to distillate the real problem, I'm not happy :)
(Sorry Wiebe, not to be personal, I know your commitment! After all I read Dutch ;) ) <\intro>
So please tell me if the correct summary is:
" In a document with many images/objects with wrapping, re-pagination stops
to work properly causing problem X "
If so, what is or are X?? Does Writer freeze, are you placing new images/content at a weird unexpected position, get stuff lost, does it work too slow ?
Hi Cor, thanks for taking time to react and I feel sorry about being not brief. If I was to defend myself: I try to be thoroughly. The very short version, I hope suiting the bill:
In a Writer document with many objects like images, with wrapping switched on and objects not anchored as character, the re-pagination process stops unexpectedly, leaving parts of pages and or complete pages blanc, resulting in a malformed document.
I've changed status from "needinfo" to "unconfirmed".
Hi Wiebe, Bruce,
Thanks for the info and your explanation Wiebe.
OK, let me make apologies too ..
I could also simply have asked: please give a brief summary. But wanted to be brave, understand it, but not spent too much time...
What I did
1 download media.vanderworp.org/.dot/.lo/test_s02e15.odt
2 changed TOC leavels from 2 to 1
3 checked document > OK
4 changed TOC leavels from 1 to 2
5 checked document > now some blank pages.
Could reproduce this twice. Set to new and will attach a screen shot.
I saved the wrong file and reopened. Now the content looks OK again.
msgbox ThisComponent.Textframes.Count shows 86 for bot orig and changed file.
This nothing lost.
Still, when editing in a wrongly updated file, without noticing, things may go wrong?
Can someone please comment (brief ;) ) on this :)
Created attachment 127286 [details]
screen pring from doc with wrong pagination
Created attachment 127291 [details]
Minimalistic test document for illustrating repagination errors
https://bugs.documentfoundation.org/attachment.cgi?id=127291 is probably a better place for this test document.
To answer the question:
This bug only affects repagination.
There is no information loss involved.
There are no stability issues.
see the same already in libreoffice 126.96.36.199 - so no regression.
Did you try to play with compatibility options like:
1/ Use OpenOffice.org 1.1 object positioning
2/ Use OpenOffice.org 1.1 text wrapping around objects
in menu Tools > Options > LibreOffice Writer > Compatibility
with both options checked it seems that the offending behavior does not occur.
If I am not wrong, the problem would be in the algorithm for direct positioning of object, see the help about these compatibility options.
Best regards. JBF
With compatibility options set as suggested, problems seem to be resolved. Seem, because in larger documents the problems come back and compatibility switches don't offer a solution then. I've tested this multiple times.
Right now, I know two solutions as workarounds: anchoring as character or put small documents in a master document and update each sub-document before pdf generation or printing. When using a master-document construction: F5 > Toggle Master View > Select sub-document > RMB > Update > Selection > repeat for each sub-document > update indexes > print/pdf.
Maybe there is another way of doing it that I'm not aware of, but using sub-documents is not a solution for me. All that I see a master document doing is copying sub-documents into sections in the master document, in effect creating 2 copies of the documents. It only then looks at the sub-documents when told to update, thus re-combining everything into one document again.
The only solution that I have found for this problem is to treat Writer as a desktop publishing application and force a page break after every page or a short, couple page section.
Simple reproduction of this repagination problem can be seen just by switching to web view and then back to normal view, though i did find another bug on the way (bug 102405).
(In reply to Bruce Byfield from comment #0)
> 1.) low default settings for general memory.
We increased the memory in 5.2 (bug 94760), so i dont think this is a factor.
> 2.) default anchor of To Paragraph, rather than As Character.
Not really an option to have anchor as character if you want to position an object at a particular place on the page and have wrapping.
> 3.) Follow text flow option is turned off by default.
So i took attachment 127286 [details] and changed all of the frames to follow text flow and the same issue didnt occur after repagination.
@Regina: Bruce mentions you in his article saying, "In a recent post to the Apache OpenOffice user's list, Regina Henschel also suggested that ... the Follow text flow option on a picture (or frame's) Type tab should not be unchecked (which it is in the latest LibreOffice version).". Can you elaborate on this? I checked 3.3 and AOO and this checkbox isnt checked by default there either.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
This bug is still alive in 188.8.131.52. Work around has not changed, add more trees, anchor objects as character.
(In reply to Wiebe van der Worp from comment #13)
> Created attachment 127291 [details]
> Minimalistic test document for illustrating repagination errors
I repro in LO 6.5+. No from 2->1, but yes from 1->2 seen at heading 3.19 and 3.20.