# Writer: Moving sections: Slow

I have a 40Mb Writer file (.odt). Only 70 pages but a lot of figures. I am trying to move sections and find that both this, and when I scroll exposing a figure it becomes v. slow. Even with only this file open LO rapidly racks up the RAM used above 1Gb (recently >5Gb). Moving sections with Navigator doesn't work at all.

Is there a way to get faster response. I have tried re-starting but no improvement.

Specs: OSX 10.14.6, 2.3GHz, Intel Core i5. Intel Iris Plus Graphics 640 1536Mb. 16Gb RAM (lots to spare). LO 7.0.2.2

I occasionally use LO on an old PC (slower and much less RAM) yet find it works faster. Is there a specifically OSX problem?

edit retag close merge delete

Sort by » oldest newest most voted

Turn off the display of graphics with the command Tools –> Options –> LibreOffice Writer –> View –> DisplayImages and objects and organize the structure of the document. Giving each graphic an appropriate name will make it much easier to navigate through the content. The graphics will still be visible in the preview, it will be printed and saved in PDF format.

The best thanks for the answer is clicking on the picture so that it turns green

more

Thanks both: 1. ajlittoz A lot of good advice. I obviously style less than I thought. But...

1. Astur: Once I switched off display, scrolling is fast.

It appears that displaying images are the main problem. Note also that when I displayed only a slit sized Writer window and so little if any image, Navigator could be used to re-order headed sections.

As 'ajlittoz' points out, images weren't the only problem, but they appear to be the main one on this OSX use.

One Q to 'ajlittoz' I have often tried putting Captions within the frame, but they always default to the bottom. I've tried stipulating 'top', but it never works. I have to manually expand the frame, drag the image down, then try to reduce the frame again. All highly inefficient. This is why I've sometimes put images, without a frame, directly into a table cell instead ...(plus)

( 2021-04-11 20:14:56 +0200 )edit

(nothing new in the edit; just removed misspellings and formatting errors)

No scrolling problem on my Linux box.

However I note several small issues which might hinder layout refresh.

## Image properties

This is "Figure 1: Feed tube confirmation record". Its wrap mode is set to Through and Allow overlap is checked. This means main text will not flow around the image. Text will be set as usual, ignoring the image which is added over it. The Allow overlap has effect when several images are close to each other. Their "proximity" is ignored and they can cover one another.

As far as I can see, you have anchored the image to an empty paragraph, different from the "Figure 1" paragraph. This is not an error but you separated the image from its caption. Since your image(s) is (are) rather tall, it is highly likely that a page break could occur between the caption and the image. A better solution is to right-click on the image and Insert Caption.

As such, the image and the caption will be both in a single frame and whatever the text flow they will always be kept together. Distance between caption and image can be tuned in the Wrap tab of image properties.

If you have several images with same properties, record all these settings in a frame style so that it can be quickly applied to all images. Built-in Graphics is a good candidate.

Beware that you are limited by the vertical size of the page.

## Table

This is "Table 1: NG …". The table is too wide for your margins. It is a very complex table, so it is "natural" to set manually column widths but you should try not to overflow in the margins.

Words in first column (those in white over gray background) are written one letter per paragraph. Since this column is very narrow, you don't need this trick. Type your word as you would do in a line; it will be split one letter per line. Don't use empty paragraphs to position the word. Instead, right-click on the cell, Table Properties, then Text Flow tab and select Vertical alignment Centered.

The advantage of the table over the image is a table can be split across pages. You can also request to repeat the heading (3 rows in your case) but it needs a lot of time to design.

Your document is not styled. Apart from the Heading n to outline your document, everything else in the contextual default style (you even have Table Contents paragraphs outside tables, showing you fiddled a lot with your document). No character style is used.

This translates to: Writer has a lot of work to do to figure out how to format the document. Everything is unique, no common factoring.

To make things worse, you document has been processed with M\$ Word in the past. This left many stray unused character styles which pollute the style dictionary and take time to ...

more

I've attached a file: p1 with an image is slow p2 with a table is not

C:\fakepath\Eg for LO.odt

more

Please repost this as a comment, see: https://wiki.documentfoundation.org/A...

( 2021-04-11 16:37:58 +0200 )edit

40MB for a 70 pages document, that's quite heavy.

Do you really need high resolution pictures? If so, you can try to link the pictures instead of embedding them (when inserting them).

That doesn't explain the issue on your Mac but it can at least improve the situation.

more

@Hagar Delest: please don't clutter the site with "non-answers". This site is not a forum but a Q&A. Entering an answer for what is in fact a comment or a request for clarification flags the question as "answered", i.e. supposedly solved, in the home page. This behaviour doesn't abide by the site rules.

Please repost as a comment. You're sufficiently senior here to understand that.

( 2021-04-10 16:45:04 +0200 )edit

Actually, the solution I propose is to change the way the pictures are handled, or to change their resolution so that the file size becomes acceptable.

It may not fix the problem with the Mac but it can still be an acceptable way to continue working on that document.

If there are better replies, then, @StephenT can select the best one, the site is designed for that, isn't it?

In addition, the ONLY way a question is solved is when an answer has been tagged as the correct one, it gives the special check mark in the question list.

( 2021-04-10 16:48:25 +0200 )edit

I assume linking rather than embedding figures would reduce file size and RAM use. However, the bigger problem that I need solved is the slow scrolling (when a figure appears) and the inability to quickly move sections (eg. with Navigator).

( 2021-04-10 20:29:39 +0200 )edit

Then what about reducing the resolution of the pics? Are they saved in jpg or png? And are png actual png or rather jpg changed into png because of the way they were inserted in the file?

Make a copy of your file, open it with an archive manager (rename it .zip if needed) and look at the /pictures folder. If photo-like pics are saved in png, then resave them in jpg and reinsert them.

( 2021-04-10 21:37:13 +0200 )edit

perhaps an issue with MacOS as the desktop manager and the widget library is not the same as on other platforms.

I have documents much bigger than 40MB with hundreds of pictures and don't experience slow scrolling. To tell the truth, I cheated: I separated the "catalog" into chapter files with ~25-40 pictures each and all are merged in the global catalog master file. And even when displaying the master (which references ~50 sub-documents), scrolling is smooth and fast. All my pictures are embedded in the subs because linking caused other problems.

Also to avoid intensive CPU usage when switching to another page, all documents are fully styled, without any direct-formatting. With direct formatting, all paragraph attributes must be gathered individually for any paragraph, while styles are cached and shared, sparing both time and RAM.

And this was years ago on a much slower computer ( some file extensions .sxw ...(more)

( 2021-04-10 21:48:15 +0200 )edit

the ONLY way a question is solved is when an answer has been tagged as the correct one, it gives the special check mark in the question list.

Your argument would be valid if users understood how this site works. Frequently (most of them are one-shot posters), they don't even tick the solving answer. We are left to rely only on the existence of answers. And regular "necromancers" like @Alex Kemp are compelled to perpetually scan old questions to finalize the task.

If you compare with StackExchange which uses the same Q&A engine, the situation there is much more dynamic. The voting system is universally understood and selection of the "good" answer is very easy. Agreed upon answers frequently get 100+ marks. Here an exceptionally good answer will rarely get a 3 mark.

There are 2688 pages of user names. Pages 330-2688 contain 1-karma names, which means ...(more)

( 2021-04-11 10:08:01 +0200 )edit

(…) This means that less than one out of 8 users will ever come back. In fact I should extend my sample to 11-karma which brings us to page 132, i.e. 1/20 of registered users.

This tells a lot about the site popularity.

Also, these users don't read manuals. They won't either make the effort to investigate about the site usage rules. They won't search for a similar question (I admit that the site ergonomics is below average). They don't know the difference between Q&A and forum.

All in all, they ask a question and don't care to give feedback, even in the case they found a solution or workaround. So, for those who really are trying, given the poor dynamics here, it is preferable to enter only high-value added answers because there will nearly never be peer review and ranking.

( 2021-04-11 10:17:36 +0200 )edit

And because users don't understand the system, we should use it otherwise? That's nonsense.

Would you stop advising using styles in Writer because most people will find it too complicated? No. Better try to educate the users.

Same here. The wiki to How to use the Ask site is not visible enough and it lacks the section about tagging a question answered. OK, it direct to another post, but what's the point? Will try to fix that if' I feel the courage to create an account.

Since +500 karma users can accept answers, why don't they do that, at least for trivial answers? That would help. Knowing that either OP doesn't bother to come back (the notification may go to the spam folder) and in this case, at least other users can spot the answered question, or OP do not agree and can untag the ...(more)

( 2021-04-11 11:17:22 +0200 )edit

I can reduce resolution of some of the figures, though it's pretty time consuming. However, for a lot, there isn't much I can do. It seems that the LO-OSX combination struggles badly with any images appearing that are >250kb. I should have mentioned that it isn't just scrolling. When you edit text, it slows to a crawl before appearing if there is a sizable image on screen. And all this is before the Gb's of RAM are consumed as you move around large sections of the document, necessitating a re-launch of LO.

By 'direct formatting', do you mean styles. I do use these as much as possible.

It's quite a problem.

( 2021-04-11 11:28:45 +0200 )edit

Can you share the file? Or make one with the same issue but with non-sensitive content?

( 2021-04-11 11:46:57 +0200 )edit