Page formatting in writer goes nuts

users
#1

I have a large document with lots of pictures currently using LO 5.1.5.2.
After doing some editing, the page formatting function kicks in
automatically but does a bad job, inserting page breaks randomly and lots
of empty pages in sequence. The total page count may increase with some 10%
due to this. I have got the impression that it is the pictures LO has
problem with since most of these extra page breaks are made where there are
pictures nearby. I have tried anchored them to the paragraph or as a
character without any effect that I can see. Closing and reopen the
document clears the problem as the initial page formatting works fine.

This is actually a very old problem, originating from the time I used OO. I
have been hoping this was a known problem and worked with. But I am a bit
confused as to where to search for the question, if it has been brought up
before. Anyone knows about this?

Thanks
Bo

#2

Bo,

#3

Thanks but I think I have those options under control, nothing strange
there. Please note that the page formatting is fine just after loading the
document.

#4

I am not sure it finishes, it looks like the process times out, or worse, crashes.

You could try to use a master document (.odm) with smaller sub-documents. It does not solve the problem, formatting is still stopping, but reformatting every sub-document/satellite can be forced after opening the odm, before exporting to pdf and or printing. On the other hand, if your document just opens correctly, you are probably creating extra work with this procedure.

From http://listarchives.libreoffice.org/global/users/msg46555.html

#5

Greetings,
I have a document that has many tables of only two columns of about 1 inch wide. I set up a Section for each table and formatted the section as three page columns to spread the table data over the page and not waste paper. As I add rows to the tables, the tables should expand serpentine fashion across the page and when the page fills, it should continue on the next page. What I was occasionally experiencing was something similar to what you are seeing. The tables would prematurely advance to the next page before filling the current page, or continue on the next page in other than the first section column, and blank pages would appear which could not be edited (the cursor could not be put in them), but were printed (negating the purpose of saving trees). This anomaly continued to my latest LO 5.0.6.3. The last time I experienced this problem, I found the Tools -> Update -> Page Formatting option and having nothing to lose, tried it. I was pleasantly surprised that the pages were reformatted correctly with no blank pages and the table flow problems were corrected.

HTH.
Girvin Herr

#6

Thanks,

Minimizing the window did not have any effect.
I have also tried to use master and sub-documents long time ago, not sure
why I abandoned that idea but I think it was something with slowness or
pagination errors during update of the master document. Besides I had to
manually fix all references to chapters etc. But it might be worth a try
again.

I have also tried to reproduce the problem using the LO user guide, but
failed so far. I thought it could have something to do with wrapping text
on the side since I have lots of pictures aligned to the right of the page
and text to the left, so I changed some figures in the LO UG but failed to
reproduce.

Anyhow, since this does not appear to be a known problem, I guess I will
continue to track down this error to see if I can pinpoint it better. Any
other ideas are welcome. It could be that the document is broken. It comes
originally from Google docs (the old version of gdoc), later converted to
OpenOffice and now LibreOffice. I think I will try to compare the xml in
the archive with the LO UG doc or another fresh document to see if I can
spot anything odd. Maybe I should try to make a new file and paste the old
doc, hoping that eventual errors stays behind? I am unable to export a
xhtml btw, LO hangs. Not sure if that indicates an error in the document?

#7

How are you inserting page styles? Are you using the Next Style field on
the Organizer page for page styles?

#8

I have only one page style, the *Default style*, where I have adjusted the
margins a bit, no more.
I guess I should have created my own page style.
It could very well be that I have misused the styles concept for paragraphs
and characters too.

#9

How do you actually apply page styles? Your description of what is
happening sounds as though you have applied page styles simply by
clicking on the page, but, from your last reply, that isn't what you
have done.

Does your Default style have itself as the next style?

#10

Sorry, yes, it points to itself.

#11

What I was occasionally experiencing was
something similar to what you are seeing. The tables would prematurely
advance to the next page before filling the current page, or continue on
the next page in other than the first section column, and blank pages
would appear which could not be edited (the cursor could not be put in
them), but were printed (negating the purpose of saving trees).

So in general things that are not text, such as TOC's, tables, frames and
pictures, that are anchored not as character can cause trouble when
repaginating.

I think it would help if some work arounds can be found, you have a
solution:

... I found the Tools -> Update -> Page Formatting option and
having nothing to lose, tried it. I was pleasantly surprised that the
pages were reformatted correctly with no blank pages and the table flow
problems were corrected.

... as an example of such a work around. For me it does not work.

So I tried to create a pure document, trying to create the problems:

* New document from default template
* Change default style (a hate double enters)
* Insert image, png, via menu, style left and right
* Insert ASCII text, Lorem etc.
* Make headings 1 and 2
* Copy everything (dragging+ctrl) untill there are ~60 pages
* Make page 1 with page break for title
* Next page TOC

Everything works fine, no problems, but...

When I change evaluate levels of the TOC to 1, everything repagenates fine.
Turning it back to a higher level, and everything becomes chaos. See
attached nabble file.
<http://nabble.documentfoundation.org/file/n4192710/04.png>

Tools > Update does not work. Work around: Close and open file. But many of
my .odm files are not sensitive to this solution.

#12

My questions were an effort to determine whether how you were using
styles was the problem. Unfortunately, from your answers, I don't think
so.

However, there are some longstanding quirks in how frames and images
work that usually kick in when there are lots of images.

I don't know any easy way to correct your problem, but in future you
might try placing images in a table, as described in this article:

http://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bruce-Byfield-s-Blog/The-mysteries-of-positioning-pictures-in-LibreOffice-OpenOffice

This solution limits options for text wrapping, but does seem to make
pictures stay where you place them.

Hope this helps.

#13

Thanks for that information. The article do show that it actually is a
known problem, a very old problem. I'm glad to see that.

I have managed to reproduce a strange error regarding pictures using the LO
Users Guide. There seem to be a case with a (large) picture anchored as
character followed by a smaller picture anchored to paragraph. The second
picture is also wrapped with text to its left, but I have not tested if
that is a condition for this error to occur. The picture 1
<https://drive.google.com/open?id=0BzKxVP7gn2uTYlpLa1UxUDRWWjA>shows this
setup. I just took two pictures in the document and arranged them as
described above. Note that frame1 (first picture) comes before frame2 (2nd
pic) in the image list to the left.

Now, when adding or deleting text before the first picture, it will
sometimes disappear as seen in picture 2
<https://drive.google.com/open?id=0BzKxVP7gn2uTclpnU3VNV182N0E> As you can
see, the disappeared picture created lots of free space, the document
became smaller so I could image this would confuse the page formatting
function. Note that the order between frame1 and 2 has changed. The first
picture has been moved after the second. So where did it go? By clicking on
frame1 I found the picture at the bottom of the page, invisible, spanning
two pages, see picture 3
<https://drive.google.com/open?id=0BzKxVP7gn2uTS2E0Zm9PZ3V2ZmM> Odd indeed.

I was able to delete all other text in this document and still reproduce
the error. That's good. (The screen shots were taken before that.) I have
uploaded this mini version of the LO Users Guide
<https://drive.google.com/open?id=0BzKxVP7gn2uTNzVvTjZCOU9jN0U> where this
error can be reproduced, at least by me. I would appreciate if someone else
could confirm the behaviour that I see. Just place the cursor above the
large picture, hit enter / backspace back and forth, which sometimes will
make the large picture disappear. This is LO 5.1.5.2 but I do see the
problem in 5.2 as well.

A work around is to place the small picture and its text to the left in a
two-column table, and keep the large picture anchored as character - that
appears to work fine. The picture in the table is also anchored as
character if that makes difference. I guess that it may take time to find
and resolve this error in LO so I will need to apply this work around. But
I have more than 1000 pictures in my doc so I need to gather some strength
first before taking that step...

btw, this was one (1) scenario - I can only hope it is the only scenario
that makes LO mess up the page formatting.

#14

This may sound "stupid", but I would like to know. . .

I see the postings about the complexity of the documents, but I have not seen any info about the size of the documents that are part of the "writing large" statement.

Everyone should agree that the odt version of the "get starting guide" or "using Writer", etc., would be a large and complex document. But how many pages in the document would be considered as the low end for "large document"?

For the last 5+ years, I rarely write [or work on] any documents over 30 or 40 pages. I use to work with documents of 100 to 500 pages. Most of those were broken up by chapter, or a range of chapters, to make the document easier to handle. Sometimes, I did have to edit a single .doc file with over 300 pages - that included graphics/photos and other options that makes the document complex one, with no "formatting style option" available to use within the word processor or none used by the original document writer[s].

For those of us who work with 30 or 40 pages in a document file, plus maybe some complex formatting options used, we may consider 40 pages as a large document, while others may consider documents need 100 or more pages to be a considered large one.

SO, is there any consensus on where is the line drawn for this document is a large one and this other is not? Does anyone know any "official" reference about this?

I know there are technical writing books that are still in use for college classes from "the early days of PCs" and even ones written before PCs came out. Each time I went for a degree in the computer field, there was a "new standard" for writing documents [technical or otherwise], i.e. changes in proper footnotes formatting, that was required to use by writers to be taken as a "professional" in whatever field of study. Before my office space, in a previous apartment, got flooded from a overflowing tub above me - I had 7 or 8 books that were the "newest standards" for writing "proper documents". Each newer book showed the updated/new standards I had to learn for my new college classes for the next degree.

It has been years since I bought a new technical writing book. So, I do not know what the new standards are or what is considered a large document and not a "normal sized" one.

#15

I see the postings about the complexity of the documents, but I have not
seen any info about the size of the documents that are part of the
"writing large" statement.

Everyone should agree that the odt version of the "get starting guide"
or "using Writer", etc., would be a large and complex document. But how
many pages in the document would be considered as the low end for "large
document"?

It is probably a bit of a grey zone. The "get started guide" does not use wrapping and apparently wrapping is causing errors during repagination. That considered, the guide is large but not that complex to recalculate. In "small" documents text wrapping around objects doesn't cause problems. But as the document grows "large", the blanc (parts of) pages creep in, amongst others depending on the amount of included objects.

  * New document from default template
  * Change default style (a hate double enters)
  * Insert image, png, via menu, style left and right
  * Insert ASCII text, Lorem etc.
  * Make headings 1 and 2
  * Copy everything (dragging+ctrl) untill there are ~60 pages
  * Make page 1 with page break for title
  * Next page TOC

When I change evaluate levels of the TOC to 1, everything repagenates
fine.
Turning it back to a higher level, and everything becomes chaos. See
attached nabble file.
<http://nabble.documentfoundation.org/file/n4192710/04.png>

Tools > Update does not work. Work around: Close and open file. But
many of
my .odm files are not sensitive to this solution.

So I found out the hard way what Bruce Byfield wrote two years ago: http://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bruce-Byfield-s-Blog/The-mysteries-of-positioning-pictures-in-LibreOffice-OpenOffice

And I noticed this bug report: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=79234

I find it sad that no action is taken because if you want to write a "larger" document with proper layout (with text wrapping), then Writer is not suitable.

How about filing a bug report again? It is reproducible, affects all users, and it is a very old problem in the core of Writer.

As for solutions: today I've converted a sub-document, changing all anchors to "as character" and problems were solved, the document is a lot more responsive too. Downside: layout is not very nice and due to lacking of wrapping text around object, the number of pages becomes considerable larger.

In this document most images have blanc spaces on the left and the right. The table solution mentioned by Bruce is used, two images on one line using left and right aligned tab stops is used and to emulate wrapping, an image followed or preceded by a frame is used - and all anchored as character. So far it works again.

#16

<snip>

Yes, I have the same opinion about how a document can get as it grows.

I use to have "fun" trying to figure out why my pages would not keep its formatting when graphics are involved. To be honest, editing someone else's document with "formatting styles" active is a much a problem when you find out the the original author tried to have "styles" within other styles, and manual formatting option as well. I tend to remove all "style options" he/she created and then replace simpler ones when the text editing was finished.

I started dividing larger documents [.odt and .doc] into smaller chunks AFTER I read an author's note by one my favorite SciFi/Fantasy author's - Piers Anthony. It was one of his "notes" that lead me to OOo instead of MS Word, and the possibility of using a Linux system as my workhorse desktop and it could be my default OS. I use Linux for 99.75% of my computer needs. I rarely use my Windows boot partitions anymore.

Piers Anthony use to write up to 7 books a year, 20 or so years ago that is - using Star Office then OpenOffice.org. Now in his 80's, he writes 1 to 3 books a year. I have almost all of his published books - with all that I could find that are no longer published and can only find as used books.

He wrote with each chapter having its own file. Kept all of his typed notes in other files. He started writing macros to make his writing process easier for 20+/- years. When I found LibreOffice back when the first version came out of the its release candidate, I started using it and then decided to send an email to Mr. Anthony about using LO instead of OOo. I have had a few emails back from him [written by or dictated by him] since I found out that one of his daughters and myself share the same "brain condition". Between the author's notes printed in the books, and then posted monthly on his web site, I learned a lot of "things" on how he wrote his books using a computer. That, and a book editor who was my wife's college roommate and good friend for more than 30 years, has helped me understand some of the ways to write and edit documents/books/etc.

#17

You can still write long documents, but you have to adjust your design.

One thing that seems to help is to link your graphics rather than embed
them, which keeps the file size down.

If you have more concrete information, it couldn't hurt to add to the
bug. However, the trouble is that only those doing documents with lots
of images -- a definite minority -- are affected by the bug.

You might also want to take the time to download my book (which is free)
and ready the chapter on frames. It represents my best thinking on this
problem, offering two different approaches, neither of which is
completely satisfactory:

http://designingwithlibreoffice.com/download-buy/

On the whole, the table solution is the most flexible, but having lots
of tables does increase the file size.

#18

More than one picture in a row, or even on the same page does seem to be
common.

From the chapter on frames in my book:

Throughout LibreOffice, frames are usually less trouble if you follow
these best practices:
- Add objects when the formatting and writing is done. The objects are
less likely to move around.

- If possible, format the frame style, not individual frames.

- Adjust objects immediately after you add them, not later. If
necessary, experiment with the exact settings first, making notes of all
the settings. Then delete the experiment and add the frame again,
applying the settings as the frame is added.

- Never copy and paste frames or objects. Delete a frame and start from
scratch if you want to move an object.

- Never drag an object to resize or reposition it. Use the right-click
menu.

- Never use spaces or empty lines to position objects. Instead, always
use styles.

- Avoid putting two or more images one after the other, unseparated by
text. The workaround suggested in this chapter is more reliable for
placing two or more images together.

These precautions seem to work more reliably in Writer than in Calc,
Draw, or Impress.

#19

FWIW on the 'large document' topic. I recently wrote a 'large' (ish ?)
document using LO Writer :

109 pages (US Letter size pages)
70 illustrations (.png format black and white)
21k words

The images were all linked rather than embedded because they too evolved
during the writing process and embedding gets the updates included.

Each image was anchored to paragraph (rather than character or page)
with 'NoWrap'. I didn't 'mess' with the image frame styles except for
the captions.

Text was all formatted using styles I created to suit my needs.

During the writing / formatting process, the only difficulty I had from
time to time was adjusting the sizes of the images. I didn't find the
graphics position and size boxes in the right hand bar to be very reliable.

I kept the whole document as one single file and loading time was never
a problem. Whenever I added or modified an image, I used File > Reload
which was pretty rapid.

I had a TOC and general index in the file, developed with LO Writer tools.

I flattened all the image links prior to exporting to pdf. Overall the
LO Writer process was pretty good.

Philip

#20

<snip>

You might also want to take the time to download my book (which is free)
and ready the chapter on frames. It represents my best thinking on this
problem, offering two different approaches, neither of which is
completely satisfactory:

http://designingwithlibreoffice.com/download-buy/

On the whole, the table solution is the most flexible, but having lots
of tables does increase the file size.

Thanks fro the reminder of the book link.

I downloaded it and forgot about it. I have not had a chance to do more than a fast look through.

Thanks for your work on this book, as well.