Some additional observations (based on more hangs):

1. If I happen to switch to another application while Ooo is active, then
switching back is impossible (I can't ALT+TAB to OOo). At other times I can come
back, but all I see is a all-white screen.

2. Scrolling rapidly with mousewheel also seems to trigger the hanging. Even a
completely unedited file can hang.

3. All panes (including Navigator and Styles pane) flicker heavily when the
document is opened. The total number of pages also changes for the first few
minutes (by 3-4 pages). 

Finally, after a few minutes, this lessens (but does not entirely cease). I have
reported this before also; and I feel this is related to the hanging/crashes.

4. The CPU reaches 50% on this HT-enabled P4 3-GHz PC. 
There is no other application running which can load the PC. 

Other parameters: 
commit: 540 MB. 
private bytes: 52 MB.

5. Restarting of PC has no effect.

As usual ;-) please send the document to mru@openoffice.org. Thanks a lot!

:) Sure! Sorry I could not isolate the problem by truncating the document. This
must have crashed at least 15 times today. I even uninstalled OOo, rebooted the
PC , deleted the installation directory entirely, and then installed OOo all
over again. That also didn't make any difference. (using Win XP SP-2).

Tried on RC3 also. I can't even open it mostly (OOo shows an all-white screen
till I forcibly close OOo); and sometimes it crashes soon after opening.

Some more observations:

1. I have sent a lot of recovery wizard reports to OOo team earlier. But OOo
2.0.4 RC3 does not create a report after recovering the document (when I press
the NEXT button in the recovery wizard). How can I start generating reports again?

2. The "white patch" I mentioned in earlier post in this bug is actually caused
by a floating "table" toolbar. When OOo stops responding, this toolbar vanishes
and leaves behind a white rectangle. I tried with other floating toolbars, and
they too had the same effect when OOo hanged.

MRU->OD: open the (confidential) bugdoc and leave it open for a while -> Writer
loops

Starting "Tools.Update.Page formatting" manually after opening seems to
workaround the problem at first.

Yes, confirmed: Manual page formatting avoids hanging.

It also confirms two observations in my second post:
(a) The "total pages" number settles instantly, and does not change afterwards.
(b) The heavy flickering in all panes stops immediately.

Now the document seems to be at peace with itself! :)

I will let you know if the document hangs AFTER some time.

yes, RC3 DOES hang even if I use the "update page formatting" command. But it
happens after a long time, which allows me to do at least SOME work. In
preparation of the eventual hanging, I have to keep saving. Each save takes
about a minute. I have to abandon the work done after the last save and the
hang, because once I got hard-coded addresses in all hyperlinks of a recovered
document; and I don't want to have that problem on my hands again.

****
Anyway, whatever factor it is, there is a clue:
2.0.3 was better than 2.0.4 RC1.
2.0.4 RC1 was better than RC3. 

RC3 is the worst: If I don't use the "update page formatting" command, it hangs
so fast that I can't do any work at all.

So a code-comparison will lead you to the problematic code.

Investigation reveals, that the layout algorithm has problems with table, which
is named "Table21"

I've made some minor changes to the document to avoid the layout loop:
- clear "Keep with next paragraph" attribute at the paragraph before table
"Table21".
- insert manual page break at paragraph following table "Table15".
- change anchor type of graphic "graphics749" to as-character.
This document doesn't causes trouble to the layout algorithm.

OD->raindrops: I will send you the changed document via eMail

Thanks!

I have several points:

1. Although you have changed the document to avoid trouble, I cannot see any
connection between the problem and what you did to the document. As a result, I
may easily land in trouble once again; because this document is under active
editing; and I may do something that causes the same problem again. Could you
tell me how you could spot the troublesome parts/properties; and how your
suggested remedies work?

2. The algorithm definitely needs correction; so that it does not react to
specific formatting in this way. Even if a document is badly formatted, it
should not become unstable.

3. Specifically spreaking of the anchoring of an image as a character, I have
raised another bug that talks about an image jumping out of a table's cell. I
had to drag it back often. Finally I tried to anchor it as a character, and it
stayed in place. Is that what you saw in this case?

4. In my document, many (inner) tables have text with "keep with the next
paragrph" property, although I have not selected it deliberately. I noticed this
aspect when I saw that some tables had skipped blank space on one page to be on
the next page; without an apparent reason. Is there some bug, or an overlooked
aspect that turns this property ON without my knowledge? If yes, how do I avoid
that?

Thanks once again!

ad 1.
Too much unneccesary "Keep with next paragraph" attributes stresses the layout
algorithm, if the group of paragraphs and tables, which wants to keep together,
are larger than one page. Especially, when the tables span over more than one
page and contain anchored objects. Thus, it is better to avoid such large
keeping groups and instead insert manual page breaks, if needed. These are my
first two changes to the document.
The third change is special to anchored objects inside table cells. The anchored
object overlaps with its anchor and the anchor has to wrap around the anchored
object. The text wrapping causes the anchor to move to the next page. Thus, the
anchored object has to follow its anchor. If now the table, which contains the
anchor, is formatted again because of an insufficiency of the layout algorithm
or because it's needed to fulfill a keeping, the anchor is moved back to the
previous page --> potential layout loop.
We are trying hard to consider all such cases in the layout, but we aren't perfect.

ad 2.
Correct.
We are constantly working on improvements/corrections of the layout algorithm.
Thus, I will also fix this problem, soon or later.
The changed document only "workarounds" the problems and I provided it, so you
can continue to work on it.

ad 3.
As I see, the document is created by importing a Microsoft Word document and in
Microsoft Word anchored object are allowed to leave the table cell. Thus, I've
implemented this behavior for OOo 2.0
To keep an anchored object inside a table cell:
- Check attribute "Follow text flow" at the anchored object, or
- change the anchor type to as-character, if possible.

ad 4.
I think this attribute is set on the Microsoft Word import.
If this attribute of a certain table changes not intended, it's a defect. If
your can reproduce such a attribute change, please submit an issue.

Thanks for the detailed answers. Yes, I have actually SEEN this, in the same
document. 

But that case was slightly different-- I had TWO images there: I had inserted a
screenshot from files; and then drawn an ellipse over it to highlight a
particular button. I saw that the ellipse was "chasing" the screenshot across
the page break, to-and-fro! However, this lasted for only a few minutes; and
after that they stopped moving (perhaps the repagination in earlier pages
shifted them both in the middle of the page.)

I have often noticed that such ellipses shift to one side; and no longer
encircle the correct part of the screenshot. Probably this is due to the
anchoring+wrapping problem. 

Yes, this document was imported from Word (but that was a LONG time ago). I will
simulate the Word import and see if a spurious "keep with the next paragraph"
attribute is added.

Haven't received the file yet; but I think I can manage it now. In fact, I need
to remove the "keep..." attribute from most of the paragraphs! Thanks once again!

Just found something:

MRU wrote in response to issue 60632 (which I raised earlier):
"Currently the "keep with next paragraph" option does not work inside table cells
(the evaluation does not consider the attribute inside table cells)."

Our current observation is just the opposite!

How can both defects coexist?

OD,

Somehow the file hangs as soon as it opens; even with RC1 (which was better than
RC3). Earlier OOo was at least allowing me to edit for a few minutes. No more. :(

When you said you'd send the file, I thought I can manage. But now I have no
choice but to use your modified file. Could you send to me through email please?

I noticed that 2.0.4 Final is available. Does that have (somewhat) corrected
algorithm? Then I will try that.

Thanks in advance!

OD->raindrops:
ad your comment about issue 60632:
It is correct, that the "keep with next paragraph" attribute isn't cosidered
inside table cells.
For this layout-loop issue the "keep with next paragraph" attribute inside table
cells doesn't make trouble.

OD->raindrops:
ad your last comment of 2006-10-13:
I didn't get, what's going wrong now.
Do you have trouble with the changed document, I've send you via eMail?
Or do you have trouble with the original document?

BTW, the current RC3 equals the released OOo 2.0.4

I was referring to my own local copy. I found that MRU's trick worked well (use
the "Update> page formatting" menu option IMMEDIATELY AFTER opening the
document.) So I continued my work on the document. 

As a result, my latest document no longer matches the copy you have corrected:
It contains many changes/additions.

That is why I wanted to use my own copy, and correct it the same way you have
described.

Unfortunately, something happened during the last 3 days' work: Now none of the
OOo versions (RC1, RC3, Final) can open the document in a stable manner. They do
NOT respond to the "Update> page formatting" menu option: The task completes 50%
to 90% and then freezes, no matter how fast I try to issue the command.

So the only option left for me is to forget about all changes I made in the last
2-3 days. But I have not received your corrected copy (I checked my spam folder
also). 

Could you send it again (to my GMAIL account) please? Thanks in advance!
MRU has the correct email ID.

***
When you mentioned "keep with next paragraph" as one of the root causes, I
assumed that it must be inside a table, because most of my text is inside tables
only. (There is hardly any text outside tables). 

That is because I have used a two-column table in each chapter to control the
flow of the text. Only some appendix test is outside tables.

So if "keep with next paragraph" property inside a table is ignored, most of the
paragraphs should not cause any problem (except the appendices).

Does your observation match with this?

OD->raindrops:
Send me your copy of the document, probably I can correct it.

***

There a lot of empty paragraphs outside the tables, which have all "keep with
next paragraph" attribute set. E.g., The empty paragraphs between table "Table15
and table "Table21".

What do you mean by "controlling text flow by two-columned table"?
To control text flow you can use "manual page breaks".

Raindrops -> OD

@"controlling text flow by two-columned table":
I meant controling the text flow in columns. I use two columned table; so that
the narrow left column serves as the left margin, and the wider right column
serves to hold the paragraph text.

When I need the full width of the page (typically to insert a large image), I
just insert a row and then merge the two columns. Then below that, I continue
with the two-column table layout.

Most of the chapters are formatted like that; only the text in the appendices is
free-flowing. That's why I thought that only the appendices can create this trouble.

***
Oh now I see what you mean: To break the text-flow VERTICALLY, I do not use
manual line-breaks or empty paragraphs inside the text. I use page-break or
section-break. So this must be thanks to MS word-to-Writer conversion. (I will
check this out, and raise a bug if confirmed.)

And the strange uncontrolable movements (and gaps) that I see must be because of
that, too!

***
Yes, I will send the latest version tonight. Thanks!

May I use your openoffice email ID (which is listed in this thread)? If you want
me to send it to SUN email ID, please send me a test-email, so that I can reply
to it.

Thanks once again!

Raindrops->OD

Although I have described the latest situation through mails, this is to record
the summary with this bug, so everything remains in one place, for all people to
see.

1. Although you were able to recover the document, I was not even able to open
the document with the same version of OOo (i.e., 2.0.4 Final). My PC is very
powerful (Pentium 4 with HT, 3 GHz, with 1 GB memory, Win XP SP-2). I have
closed all other applications to avoid loading. Even then my attempts failed.

DEFINITELY there is another PC-specific factor here. Could it be the Java
version we use? I am using J2SE 1.5.0_06-b05.)

2. After receiving the modified document, I have selected the ENTIRE document
and reset the "keep with the next paragraph" property of ALL paragraphs. But
even now the document fails often. If I use the Tools> Update> Page formatting,
the repagination progress bar stops and then OOo hangs. The CPU reaches a steady
50% and remains at that level. I have noticed that the progress bar ALWAYS stops
at specific points (either 55% or 20%). I guess that at these points, the
algorithm must be doing something that is prone to "infinite aloop" behavior.

This is another issue that can be investigated.

3. Under no circumstances should an algorithm be allowed to loop endlessly.
There should be a limit on the number of loops: Once that limit is reached, the
algorithm should exit from the loop. Even if the document is NOT fully optimized
at this point, at least the OOo does not hang, and the user can go on working!

Given the choice between losing all work and an odd-looking document, I'd take
the latter.

4. The anchor and image should not be allowed to enter an endless chase. They
should be moved together: Once a author has arranged them in a certain
configuration, Ooo has no reason to change that. 

Specifically, the algorithm has a problem when images are placed in/around
tables, with their anchors placed INSIDE a cell. (I had to do that to stop the
images from drifting away from the text. See issue 60757 for a related problem).

Even here, there should be a loop counter that exits the loop after certain
iterations.

OD->Raindrops:

ad 2:
Do you already submitted a new issue for this? If yes, please send me the issue
number.

ad 3:
You are right on your statement about an algorithm.
But, the problem here is, that the current text layout algorithm is implemented
by hundreds of methods, which calls each other in a lot of manners and
situations. There is on method instance that loops on the document pages to
format them. Here, we have already implemented an loop control, if again and
again the same pages are formatted. But, if a layout loop occurs on one page,
there doesn't exists such a loop control. Thus, if I count on your statement
about "looping" or "wrong layout", it makes sense to implement such loop
controls in general. I will discuss this with the responsible developers.

ad 4:
Currently the user can arrange anchor and object into an endless chase.
E.g. paragraph with tree lines and an object with wrapping style "No Wrap" and
vertical position "center to paragraph text area". No solution exists for this
configuration - above and below the object couldn't be the same count of text lines.
In such cases the layout algorithm tries to find a compromise.
If you have a concrete problem, especially when the anchor is inside a table
cell, please submitt an issue - I will take care of it.

For issue i60757, I only have the document created by MRU. But, you have stated,
that this document doesn't show the described defect. Could you provide the
corresponding document and describe, which object you want to move?

@2: I have raised Issue 70662.

@4: Yes, I still have problems described in the issue i60757 in this same
document. That issue was raised so long ago that I had given up. I will try to
experiment and let you know the image that misbehaves in such a way. Mind you,
it is very difficult to isolate the problem in a single-page document.

I have seen other TWO other problems with images placed in tables:
(a) The initial problem that I noticed was that the panes of the file blinked
heavily. I tried going down the file to see what was happening; and I observed
the following: I had a screenshot, over which I had placed an ellipse (to
highlight a button). This image was crossing over to the next page, and the
ellipse chased it. then the image jumped back to the previous page, and the
ellipse followed it. This was repeating endlessly. 

(b) As you have seen in the sample document, I merge the left+right columns of a
row to accommodate wide images. One such merged cell contained only an image;
nothing else. The image was anchored to an inside corner of the cell. That image
always jumped out when I was not on that page. I used to notice that only when I
returned to that page (or when I fired a pdf).

Finally I changed its anchoring to as character, and it stayed put.

I will see if I can repeat that. But here also I am not sure If I can create a
single page sample.

Apart from the two suggestions I made in earlier post, the algorithm has many
more defects:

(a)Why does the algorithm launch every time I start the document, and do heavy
work? (Even before entering the endless loop, it can change the total page count
by 6 in my 350-page document!). I created a pdf file and sent to some reviewers.
When I received their comments with page numbers, I could not make any
connection, because that text in my odt file had shifted by 3 pages! The next
day the text went 2 pages to the OTHER side!

(b) Why does it change the "total pages" count by a different amount? If I do
not do any work in the document, but simply open the document, the algorithm
immediately starts working, and arrives at a different total page count! Why is
it not repeatable?

(c)Apparently the algorithm shifts some of the content to other pages. But even
then OOo not consider the document changed! Why? (The "save" button is still
grayed out.) 

If OOo treated this changed content as a modified file, the user would be asked
to save the changed document before exiting; and then (hopefully) only a little
work would remain for the next session.

(d) Why is this long-duration process not ESCapable? The user should be able to
terminate it by pressing ESC.

A new observation in the CORRECTED document (where ALL the paragraphs were
edited to reset their "Keep with the next paragraph" property):

This document was also crashing the OOo repeatedly. I tried to open the document
using two different methods (described below), but got identical results:
(a) Start OOo first, and then open the document from its File>Open menu.
(b) From Windows Explorer, click on the document.

The trick suggested by MRU (immediately run the Tools>Update>Page formatting)
also failed; and the OOo kept hanging.

Finally I tried a new experiment, and it seems to be working: I clicked on some
nodes of the "Headings" tree in the Navigator. OOo responded well, and
thereafter did not hang for a long time.

But if I try to use the vertiocal scroll bar (and especially the mousewheel) to
scroll down the document, it actually triggers the hanging.

I think there is a clue here.

OD->raindrops:

ad your comments from 2006-10-25:
ad (a): The text document is stored in OpenDocument file format, which doesn't
contain any layout information about the text document. Thus, after import the
text document has to be formatted.

ad (b): This is a defect. Can you please submit another issue for this defect?
You can directly assign this issue to me and send me the document via eMail.

ad (c): This seems to be also a defect. Thus, the same as for (b).

ad (d): This is a good suggestion, on which I've already thought about. Please
submit an issue of type "enhancement" or "feature" for this request for enhancement.

ad your comments from 2006-10-30:
Can you please send me the document via eMail?

I apologize for asking you to submit more and more issues and asking for the
documents. But, for the handling for the fixes and for the quality assurance
people, it is better to have separated issues for each of the problems. Thx.

Sure- No problems at all!

But if all details are already submitted in a bug, the QA people should have a
policy to split the original bug themselves. Bugzilla already has bug-cloning
facility. That approach would also make sure that dependency is properly
recorded; which would help the developers (on the other hand, the average OOo
user is not trained in using Bugzilla).

Just my two pfennig. :)

I will submit separate bugs and put the links here. Watch this space!
I will also send the latest file tonight.

Raindrops->OD,

I have raised the following issues: 
Issue 71028, 
Issue 71030 and 
Issue 71031. 

Also see Issue 60757 and Issue 70662 for related problems.

Although these issues are split for ease of management, they are closely
related, and should be considered together.

I've already closed issue 71030 as WONTFIX, because the OpenDocument file format
can't contain layout information.

Issue 71031 is from the point of view of the Writer an enhancement.

Issue 71028 is still unconfirmed, because I'll wait for the document to
reproduce the described defect. BTW, I can't be assured that office document
look the same on each environment.

Now the document has grown to 355 pages. I was using OOo v2.1 till yesterday;
and it worked stable for most part, except a single crash. After that crash, the
recovered document lost formatting for some paragraphs, such as bold,
superscript, etc. I had to do that once again. 

But apart from that one crash, everything was OK.

Yesterday, I downloaded the latest version m197, Because it has enhanced options
for "export to pdf", which I want to use for my manual. But this version hangs
within a minute of opening the document. 

My trick to click quickly on the Headings in Navigator panel does not work.

I am providing this feedback because from the algorithm point of view, something
has changed for the worse in m197 as compared to v2.1. This could provide a clue
for your investigation. Please check!

I am having a problem which sounds similar to this:

I have a 300 page master document with about 39 subdocuments. It has a table of 
contents in the master document which runs for about 1.5 pages. The document 
loads fine, and I can start working but OpenOffice 2.3 hangs about 15 seconds 
later whether I leave it idle, or start editing. If I right-click the table of 
contents and go "Update table" within the first 15 seconds, it doesn't 
subsequently hang until I make a big change like inserting or removing a 
subdocument. Continually updating the TOC after every change keeps OO from 
hanging; but of course isn't practical. I got the idea of updating the TOC from 
this bug report; using "Update All" also prevents OO from hanging.

Unfortunately I can't send the document as it is unpublished and very personal, 
but I wanted to raise the issue because hangs caused by background processing 
are very nasty. You're in the middle of something and then... hourglass!

according to release status meeting -> 3.x

*** Issue 93684 has been marked as a duplicate of this issue. ***

this issue is still present in a 300m15 build - 160 p document with 700+
objects. any progresses?

Sorry, no progress so far.

Reset assigne to the default "issues@openoffice.apache.org".