Randomly inserted page breaks driving me crazy

[annamax]

Hi all,

during the past three days I spent a lot of time fixing a 200 page document layout for printing (user manual). It happened that the table of contents did not match with the actual page numbers exported to the PDF, so I wondered. My investigation so far lead to the conclusion that Writer seems to insert (unnecessary) page breaks at places with images (most of them right-justified, following the text flow).

The weird thing is that everything is ok while I edit the text until I do a "Update Everything", or at least update the TOC. As soon as a new page layout was requested, the mess occurs. That is, even if I fix the page breaks manually, after updating the TOC new random page breaks occur. If I fixed place A, it occurs at place B, and so forth ...

I am a relatively experienced layouter, but this is driving me nuts!

As the issue is related to images that follow the text flow, I suspect a bug with the pagination code.

Any idea?

Thx
Andre

[Hagar Delest]

Can you create a sample file and upload it (see here: How to attach a document here)?

[annamax]

Hm. That would be difficult as the document is confidential. Do you know of a tool that replaces all text with equivalent "lorem ipsum" ? I mean, something that anonymizes/randomizes an existing document while keeping its structure and layout? The development community should have such a tool. Would possibly greatly help with finding bugs.

Andre

[Hagar Delest]

Yes, see here. I'll update the tutorial about attachments.

[annamax]

Thanks for the hint! This xxxx xxx xxx-xxx "xxx" (xxxx,xx) looks really cool.

However, this would still leave too many images and other information in the cross references and other meta data (named after the product features, or incl. company details and urls, for instance). I don't have the time currently to edit the bare XML.

I worked around this by manually setting page breaks at least every 3-5 pages. This was tedious, but allowed me to move forward at least.

Writer definitely has a bug in document formatting regarding text flow and images. I experienced this years ago already but forgot about it. I would guess the bug is already filed.

After this project, I will likely switch to FrameMaker8. It's expensive, but reliable. I would not recommend OO Writer for structured technical documents with more than 200 pages. The extra work needed to check and check again whether the layout is correct or if some cross reference got mangled, that's simply too expensive in the long term. I think it's a shame, because OO Write has so many great features and 2.4.1 is really stable.

Andre

[TheGurkha]

Success or failure with OOo often revolves around the consistent and correct use of Styles. If you don't use styles, in my experience, anything complicated is rather fraught.

[annamax]

Yes, sure. I know. The document in question is built on styles from the ground up. I even use styles for graphics frames and numberings. I generally view documents as a hierarchically programmed content database (which a user manual actually is, even more so when the content is in many different languages).

The task for this project was to provide content in two languages and deploy to various target formats, i.e. user manual on screen (PDF) with linear layout, PDFX-3 (CMYK) for offset/digital printing in color, PDFX-3 with mirrored page layout for printing in B/W, compile searchable online help in HTML format and extract individual chapters as bulletin articles for newsletters.

Andre

[foxcole]

Word processors are unfortunately not designed for page layout, they're designed for content creation. For tight control of page layout, the word-processor-generated content would be imported into a page layout program such as FrameMaker or Scribus.

That aside, we all realize that computer programs don't do things randomly, that there's always a cause. Perhaps for the sake of research you might find time to finish "dummying" the problem document (or part of it).

For images:

If the image is captioned, it's inside a text frame container that keeps the caption with the image. Clicking on a captioned image actually selects the text frame. Press Enter to put the frame in edit mode, then click on the image inside the frame to select it. Delete. The text frame remains unchanged and retains all the anchor and wrap settings that affect how the frame interacts with the body text.

If the images are not captioned, you could change your Caption paragraph style to 2pt, which will create the text frame container without appreciably changing the spacing or size of the text frame. Right-click on the image to add a caption, change the category to <None> so it doesn't insert any unwanted text, then delete the image as described above.

It does sound to me as though these images or the paragraphs or other features they're anchored to have some kind of formatting that pushes the images to the next page, but since I can't re-create what you were seeing, it's hard to diagnose without being able to actually look at a problem file.

[edwin.gersbach]

Have there been any findings about this problem?
I encounter the very same difficulties in a 419 page document containg some 600 pictures, mostly in frames with a caption, and douzends of tables.

The additional brakes occure anywhere in the document, sometimes right before a picture but also just between two paragraphs.
I can get rid of the breake by hitting return on the last paragraph of the page and delete ne newly created paragraph afterwards. However, as soon as I recreate the TOC the breake is there again. If the break occures on a picture I can get rid of it by altering the attachment typu from paragraph to character or vice versa.
I started using oo-writer 2.? with this document some 2 or 3 years ago after having too many problems with MS-word. At that time the document contained less than 300 pages and caused no problems until it grew to some 350 pages. Although I kept up with updates - I'm now on 3.1 - the problem got worse each time I added new contents.
I could make the document available, however the .DOC file itself is 530Kb and a zip file with all the included pictures is 42Mb. Maybe can reduce the latter by converting the pictures to less pixels and quality.

Edwin