Page formatting in writer goes nuts

I too have that book on the reading list, it's been there for too long now..

As I show in the other thread, the image problem does not seem to be
(solely) related to "large" documents as I could reproduce one kind of
error in a one-page document.

Otherwise I guess a document can be as large as it need to be and still be
manageable. There is for example a difference in need between a book
written from top to bottom and a large technical specification which is
updated here and there and that contains internal references back and
forth. It was quite some time since I evaluated the master document
function, maybe it has evolved now to handle navigation and references
better than in the past?

The image problems can hit any document, but they do seem to be related
to file size. Or, at least, the larger the file, the more likely the
problems are.

However, it is all very unclear, which is the main reason it is not
officially recognized as a bug (or, perhaps, a series of bugs).

This whole thing has the feel on none linear functions gone out-of-order wrong.

That is to say, there are two or more functions that can apply to organize placement of images within a document.

Initially, they start at the same time, within the tolerance of the processor/motherboard. The more they function, the more they get out of sync until it can't complete in the way we wish, but do complete as a process.

Some get less failure and others get more.

What is the order of priority and how does it restart on failure? Does one wait before doing another?

Any thoughts?

Kracked Press wrote:

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.

Document length does not correlate with document complexity.

But how many pages in the document would be considered as the low end for "large

document"?

That depends upon the type of document.

When I did a cut and paste, the tables collapsed.

Words per document.

The first line is, with three exceptions, the number of words in the
document. The three exceptions are words per page.
Words are calculating using standard printing metrics.
The second line is the type of document.

0-100
FictionFactor Micro-fiction
0-7,500
SF Short Story
100-1,000
FictionFactor Flash fiction
250
Words per page for fiction
400
Words per page for academia
832
Words per page, single spaced
1,000
F100 Short Article
1,000-1,500
Length of a ten minute sermon
1,000-2,500
F1000 Medium Article
1,000-7,500
FictionFactor Short story
2,500 – 8,000
F1000 Long Article
4,000-7,000
Kindle candy
8,000-15,000
F1000 Maximum Length Article
17,500-40,000
SF Novella
20,000-30,000
Middle Grade Essay
20,000-50,000
FictionFactor Novella
40,000-50,000
Upper Middle Grade Essay
40,000-60,000
SF Novel from 1960s
40,000-80,000
SF Novel from 1970s
45,000-50,000
How To books
50,000
Comprehensive Report
50,000-110,000
FictionFactor Novel
55,000-90,000
Young Adult Fiction
60,000-70,000
Length of a mystery
64,531
Amazon: median length of all books
7,500-17,500
SF Novelette
7,500-20,000
FictionFactor Novelette
70,000-115,000
Adult Fiction
80000
Young Adult SF Novel 2010
90,000-120,000
SF Novel 2015
100,000
PhD Dissertation
100,000
Number of good words that writer writes per year
100,000-115,000
Science Fiction Novel 2010
110,000–10,000,000
Epic Fiction
200,000
Biography
240,000
Short Mega-novel
300,000
Number of words a writer writes per year
1000000
Average length mega-novel

As such, if you treat software documentation as a "How-To" manual, the
target is roughly 50,000 words.

The caveat is how the target audience is, and why the documentation is
being written.

that included graphics/photos and other options that makes the document complex one,

Graphics, tables, charts, and illustrations make for complex documents.

SO, is there any consensus on where is the line drawn for this document

is a large one and this other is not?

Pages per Document

The first line is the number of pages in the document.
The second line is the type of document.
The third line is where that document is used/found.(Document Aim)

1
Cover Letter
Article submission, job application, etc
1
Press Release
Brief information for a broad audience
1
Editorial Preface
Short summary of an issue
1
General Article
Education of the wider public
2
Curriculum Vitae
Career summary
3
IGAS Short
Double spaced short Report
5
Patent
Protection of technical innovation
10
Research Article
Presentation of primary, original results
10
IGAS Standard
Double spaced report
10
Number of pages of a short story
Short Story
15
Training report
Education
15
HAWU Report
Double spaced report
20
Review Article
Review of Knowledge in a domain
20
Expert Report
Analysis of Knowledge
25
IGAS Long Report
Double Spaced report
30
Industrial Report
Research & Development
100
Book
Education
200
Thesis
Research

Does anyone know any "official"reference about this?

For those two tables, I didn't write down my sources. I started
collecting the information, purely for my own use and benefit.
In theory, I could locate the sources, using either _Google Search_ or
_Google Scholar_.

that was required to use by writers to be taken as a "professional" in whatever field of study.

Virtually every field of study has its own style manual. _The Chicago
Manual of Style_ is the usual fallback, for style manuals
developed in, or for the United States. Usually, but not always, the
style manual will state which edition is to be followed.
When a specific edition is not provided, editors get into big fights.

not know what the new standards are or what is considered a large document and not a "normal sized" one.

The working assumption of current technical documentation manuals, is
that the content will be presented online.
As such, page length is ignored.

jonathon

Philip Jackson wrote

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

...

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.

I really start to believe that wrapping is the only thing involved when
re-paginating crashes (or stops unexpected).

In my Q&D test-document from scratch:
71 pages A4
ONLY 1 image (cloned several times)
19k words
doc. size < 50kB

Optimal page wrap is used and LO stops re-paginating during the process,
reproducible.

I don't think sticking to style sheets or using linked or embedded objects
are the real problem here. What you describe is a welcome alternative to
using "as character" anchoring while avoiding text wrapping. Welcome because
"no wrap" can be defined in all frame styles, making the work flow a lot
easier.

Couldn't resist to test this with a troublesome master document and it looks
good. The only drawback is that I noticed spontaneous resizing of bitmaps
which I did not notice when using "as character" placement.

Sometimes I have issues with graphics/photos within the text that are high resolution - i.e. 600 to 1200 dpi. I have a laser printer that prints out at 1200 dpi so I tend to make sure that I have the graphics/photos are at that resolution and for the physical size on the printed paper - 4x6 inches at the maximum resolution for the printer that I will use to print a physical copy. Exporting to PDF files are set for maximum of 600 dpi. The same with my inkjet printers.

SO, that might be part of the file size issue. Also I either set wrap for no-wrap or to wrap on the right of the image.

The problem that several pictures change its place, remember me how the images are placed in text with the program LaTeX. That program is famous for being the first program (since 1979) that was able to diagram automatically text.

LaTeX has rules of how many diagrams are allowed in a page accounting the space that uses. Generally moves the graphics (or float objects) downstream in the text until fits acording to rules to position galleys of text and floating object.

LibreOffice and MS Office too, has also problems related to image positioning and with both programs I have reached that is preferable to have images not surrounded by text and positioned between paragraphs, fixed or anchored to characters. That's not the way as MS Office works by default, but that can be changed in program's options. LibreOffice by default anchor the images to the paragraph, which is good, but the figure frames allows text flowing around the image. But if you insert the image and not instruct LibreOffice to add a frame, will add it anchored to a character.

Can you clarify how you do "not instruct LO to add a frame" to get it anchored as character?

If one adds an image in an out of the box new document (insert > image), the frame style is "graphics". Changing this style to "no wrap" is a logical step, but that is not what you mean, right?

I could reproduce the behaviour as you described. It is odd that the big frame plus picture cover the margins, but that doesn't seem to be the problem.

The picture below is anchored as paragraph and that "explains" the behaviour, magical disappearance, after giving an enter.

Anchoring the second picture as character makes it stable again. And making a bit more space between the picture by putting an empty paragraph before the anchor of the second picture works as well.

It made me a bit curious, maybe the document is a bit contaminated, maybe something else. So what I did is saving the bitmaps, saved text as ascii, created a brand new document, inserted everything and, surprise, exact the same problem. So a one page document with two pictures is enough to get into trouble. Even worse, if the pictures are removed from the frame, same result.

If you would like to give it a try: http://media.vanderworp.org/.dot/.lo/test_s03e24.odt

Thank you, I tried your document and it indeed demonstrated an unpleasant
behaviour.
May it is time to file a bug report in the hope that this can be corrected.
I hope I am free to attach your example as well?

Feel free to do so. I really hope it helps stressing the subject.

I've added the text below to the bug report of Bruce and reopened it - https://www.libreoffice.org/bugzilla/show_bug.cgi?id=79234

I adjust the following option.

Menu: Tools -- Options -- LibreOffice Writer -- Automatic caption -- untick "LibreOffice Writer image"

After that, when I copy an image it get a character anchor, but if I insert an image from a file on disk it gets a paragraph anchor.

Thank you Wiebe for updating the existing bug report, that should be
enough. However their reply indicates that it may be difficult to solve.
Not sure that status *needinfo* means, if they want more info from us. I
hope they will take a look at this bug as it is easy to reproduce.

I have seen similar problems with pagination in tables and frames too,
where no pictures were involved. Starting with this pic bug, I hope it may
solve some other bug too related to page formatting.

I used to have this problem frequently in LO 3 or 4 or 2.4 (a while ago). My documents are typically 10 - 50 pages, many illustrations/images.
All types of wrapping, images next to images, images next to tables. Images with draw objects (lines and arrows) to tables.
My documents have not changed but I must be working differently, anticipating the problem, as this rarely happens now.

I put most of the problems down to the way LO handles anchoring. Way back when I was using Smartsuite on OS/2 images, etc. had anchors that you could move.
In LO the anchoring is random (technically probably not random), you cannot anchor an image to a paragraph or a character. You can anchor to paragraph or to character but LO decides which one and where and this can be really random. You can move the anchor, but it doesn't stay where you put it. Sometimes this anchor goes all over the place, try placing an image next to a table and watch the anchor move into the table and out again as you adjust position.

My supposition is that LO gets lost in its attempt to find new anchor points at times when the document flows, rather than using anchored anchor points. I.e. place an image next to a table and anchor to the paragraph above the table (description) or below the table (table title). Then try and anchor the draw object to the same paragraph that positions the image.

In the above example I will anchor to page and have no problems, sometimes I have to adjust position manually when the test flows but it avoids the issues of the complete reformat when an image rolls over to a new page and LO can't decide where to anchor it. Other cases I anchor as character or to character.

I am not sure how you could put this in an instruction, be aware of issues and adjust your work methods accordingly.

steve

I have noticed another odd behaviour which may be related to the "picture
problem" vs page formatting.

I have a page in my large doc with only text. This first picture shows the
content when the document is freshly loaded.
https://drive.google.com/open?id=0BzKxVP7gn2uTTTJSdzBBUkNRQ00
Then, after a change somewhere (that does not affect the page count), bot
sure exactly what triggers it, it becomes
https://drive.google.com/open?id=0BzKxVP7gn2uTT3ZJdzA1cHp3U2c

Notice that the spacing between the lines has increased and that the last
line from the first picture now has spilled over to next page.
Of course, this creates seemingly unmotivated changes in the page
formatting.
Anyone has an idea what is going on here and if I can influence this
behaviour?

Thanks

I have had this one quite frequently as I edit the same manuals from Linux, Mac and Windows machines, all in LO.
I found that the cause was that the font Arial was not the same on all machines, so I took my font package from Linux and installed it on all machines I edit on and now the jumping lines have stopped.
Steve