Hi Bruce,

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 :(
So...

(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.)

Cheers,
Cor

Cor:

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 ;) )

Cor

"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

let's close this one for now. Sorry. Improvements may still be possible, but as explained, that needs different reports.
Ciao,
Cor

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

<intro>
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 ?

Thanks!

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".

Best, Wiebe

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 :)
thanks!
Cor

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 3.3.0.4 - 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.

This bug is still alive in 6.0.6.2. 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.

Please retest.
No repro in
Version: 7.3.0.0.beta1+ / LibreOffice Community
Build ID: ecfb83d7463bed7c89baeccc03286c1ac9956d70
CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

Using attachment and changing "evaluate up to level" 2 -> 1, OK, then 1 -> 2, OK, I can reproduce the issue in:

Version: 7.1.0.3 / LibreOffice Community
Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

But not in:

Version: 7.2.7.2 / LibreOffice Community
Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Nor in a recent master build.

Seeing Bogdan agrees, closing as "works for me".

Confirmed "works for me too" based on media.vanderworp.org/.dot/.lo/test_s02e15.odt
Many thanks!!