Hi there.
Opening a large Writer file takes ages since the release of 24.x. Small files are no problem. The timer shows 42 seconds from the time I clicked on the file in LibreOffice’s Recent Documents to the time it’s ready for editing. The file is a plain text file. And what confuses me is that the same file took about 20 seconds (or less) to open before the 24.x release.
What has happened? Can anyone help me get back to the good old days, or better?
Many thanks for your help.
This is contradictory: either it is an .odt or a .txt but can’t be both.
In case it is an .odt, did you misuse line breaks Shift+Enter instead of paragraph breaks Enter to separate paragraphs? If you did so, you end up with a huge paragraph. I suspect that internal text management requires that paragraph contents be totally loaded in memory. Then you put an important stress on memory which the OS (you didn’t name it) handles as much as it can.
Give more information about your file or attach a reduced version of it (max. 1 page) for investigation.
Sorry for the confusion: it’s an .odt file with text only. No, I did not abuse Enters. This sharp increase in wait time has not been there since forever (see my first post). And during that time, the file size has increased, but not by much. And the sluggishness started right after a software update. Unfortunately I can’t remember which one, but my guess is the 24.2 update.
Thank you for your reply.
Nevertheless attach a sample excerpt of your file for analysis. There might be a change in internal algorithm which could make your file very sensitive to your styling habit.
For huge text bodies with only line breaks, there was tdf#162663, fixed in 24.8.2.
This is what I feared: your document is entirely direct formatted. This adds up to the regression problem. Direct formatting has two consequences.
It grows your file size because every format directive is unique and can’t be “common-factored”. It has to be explicitly included on every use.
Since direct formatting must be interpreted on every occurrence, it can’t be “pre-computed” for all similar applications as can be done with styles.
Independently from the regression issue fixed in the “next” release, you should learn how to use styles. They give you tremendous power, versatility and “comfort” to format and layout your text. They also considerably speed up text flow because of the methodic and organised structuration of the document.
Start by reading the Writer Guide for an introduction to styles. Then practice a bit on scratch documents before converting to this workflow.
Now that you mention it, I remember that a few years ago someone suggested that I get used to styles. And we even tried it together on my document, but the main problem is that the “third column” sometimes forces different widths on itself and on the “second column” (example attached). I also didn’t like the layout changes I had to make to fit all the requirements into the styles. I can’t remember if there were any other problems. On the other hand, I can see all the advantages of Styles, which I would use immediately if the layout result was satisfactory.
Another suggestion was to put all the data into a spreadsheet, but then my whole layout would be lost.
I guess the upcoming regression fix will shorten the wait a bit.
Do you see any “serious” drawbacks to leaving things as they are?
Thank you very much.
Example.odt (25.2 KB)
Your files show nothing like what tdf#162663 was about. If you mean that regression fix, then no, it’s about something else. I mentioned it before you provided a sample; the bug was about a huge paragraph with only line breaks inside.
Here is a suggestion based on table layout: Example-ajl.odt (20.5 KB)
However, as I have no specification about what you want to achieve, consider it as a quick’n’dirty attempt.
I created 4 paragraph styles:
- Word for the term in the first column
-
Definition for the explanation or definition of the term
It is a hanging indent paragraph so that the left paragraph limit lines up with the first word of the definition. Note that I have no idea about your A, R, S, U, X labels. Before text and First line indents need to be adjusted since you may have multiple labels. - Translation for the third column
- Variant (as a descendant of Word) for the compound expression(s) in the second column
Some tuning is necessary if you want extra space between “word groups” (mainly in Word and Definition styles).
Don’t use “cross-column” leader lines. I find them rather ugly. In addition, I implemented them thanks to an “out-of-spec” behaviour of Writer. This means they are not guaranteed to work if internal algorithms change or if the ODF specification describes more precisely the tab feature I abused. Also the leader lines will align correctly only if Variant and Translation styles remain “compatible”.
Note that with clever styling, your document size decreases from 25kB to 20kB. And the benefit will be tremendously higher on your full document.
@ajlittoz
Please give me a few days to process everything. I will send you my feedback. At first glance it looks good. For now, all I can say is thank you for your help and example.
Hi. Can I ask you a few questions? I have attached a
Editing Layout.odt (21.0 KB)
(no styles, just table properties).
Is it possible to have this layout for editing the document, but only have a layout like the “Print Preview”
for looking up records? Are the table properties enough or do I need to add some styles? Do you see any problems?
This document is intended to serve as a dictionary between English<>German. On the left are the German or English words to be translated. On the right are the English<>German translations. In the middle are the meanings of the words to be translated and the translations. The abbreviations in the middle and at the beginning of each entry classify the type of word, e.g. noun, verb, etc. Also in the middle, at the bottom of each entry, are possible common expressions containing the word to be translated, abbreviated here by ~. There is no meaning entry for these, and the translations are on the right.
Thank you for helping me get closer to my goal.
What do you mean? Print Preview just shows how the document will look when printed, i.e. without the visual clues like page areas guidelines, table hints, formatting marks. If your question is about the formatting hints, configure them in the View menu. But I highly recommend you keep them visible because they provide a valuable aid about what is really present in the document.
You definitely need styles. Styles are not only shortcuts for a collection of typographical attributes; they are primarily a way to classify semantically portions of text. In your case, I suggest your create German and English paragraph styles for the cells containing such translatable words, Meaning for the center columns and Expression for the common expressions.
Yes. Without styles, you’ll spend a hell of a time to tune your presentation and you won’t be sure of the consistency of it. In the first step of your work, don’t worry for the exact look. Make sure you use style consistently to make a distinction between the various types of text. This is the most important. After that, modify the styles to reach a nice-looking presentation. Look update is instantaneous across the document when you Apply or OK the styles provided, of course, that no direct formatting hides the styles.
Please ignore the print preview question. I was just thinking of creating this project in another application, such as Calc, to see if I could get a better presentation, not for editing purposes but as a reference document.
I have attached a revised table (with styles). I’ll try to do the beautification once all the data is entered. Do you see any problems or ways to improve?
Styled Table.odt (22.7 KB)
I just have two questions:
a) Is it possible to save the layout of this table (width of columns, etc.) in Styles, as I’m thinking of starting the table from scratch for each letter of the alphabet? If so, how?
b) Long translations like the one above in “Secondary School Level I Certificate” are very rare. What possible changes would you recommend to shorten this entry to free up space in the middle column?
Once I’ve sorted the above, I think the big job will be to insert all the data from the previous document into this table. I was wondering if I could contact you in the (rare) event that I hit a brick wall at the table in the future, and if so, do I do so through this thread?
Thanks again for your help. Appreciated.
@ ajlittoz
My lights went on. Finally! I’m busy transferring the old dictionary into the new (styled) one. Thanks for all your help.
Deleted post.
Sorry, but got sick of LibreOffice. Installed OpenOffice which works like a charm.