LO Writer is very slow to open somewhat large files (6-7MB). This has been happening for a couple of days only, presumably since an update of LO, altho I don’t recall one taking place. Perhaps lost in a bigger distribution upgrade.
I do use styles, but… I have 2 systems on different partitions (on different HDs), both with KDE Neon Plasma 6.3.5, Ubuntu kernel 6.11.0-26 and LO 24.2.72.
I have tried to use styles consistently, but unfortunately when changing systems, things come out differently. I confess also to some confusion with templates. The result is that sometimes I have the body text style with Liberation Sans instead of Nimbus Sans L;Arial. I fix it by making sure body text is in terms of the latter, then selecting the offending paragraphs and applying body text by double clicking on it.
Could this leave me with some direct formatting which could slow down loading?
As I said, the problem is only around for the last couple of days. And I tried loading an older version of the file, but the same problem persists.
This is a new question as suggested elsewhere on this forum. But I see I have a reply there which probably answers my questions. https://ask.libreoffice.org/t/very-slow-opening-of-large-writer-file/111466/24
This may be the cause of inconsistency. What you write is CSS syntax to choose Nimbus Sans and to fall back to Arial when the former is not found. I am not sure if this is accepted by Writer. I had issues with it a couple of decades ago. Syntax of font selection has been extended to account for fonts with configuration parameters. I don’t remember if the semicolon is accepted the same as in CSS. From a quick test, it does not seem so. At least, results are inconsistent.
So, don’t try to mimic CSS. Choose a single font in your style definition. If the font is potentially not installed on the current machine, use Tools>Options, LO>Fonts to configure the replacement table.
Yes. Applying a paragraph styles has effect only in the paragraph layer. Direct formatting lives in the upper layer and always overrides styles (this rule is not a blunder; it is logically necessary to provide easy solution to non-trivial issues – but don’t use it routinely; formatting with DF requires super expert skills to achieves deterministically what you want, contrary to common belief). The only way to get rid of typographical DF is Format>Clear Direct Formatting or Ctl+M applied on a selection. Be aware that some DF (usually the non paragraph or character styles related DF) are not cleared by the command. This is one of the numerous traps of DFs. Once again this limitation is not a mistake.
Most responsiveness problems come from the stress caused by direct formatting and inappropriate usage of “objects” (non-text additions like frames or worse drawing objects). As soon as a document is larger than 3 pages, styling becomes mandatory. Otherwise, maintenance and tuning of the document is a nightmare. DF is encoding as unique (=unshared) directives everywhere it is applied. On the contrary, styles are recorded only once and simply “referenced” from the application location. This contributes both to file size reduction and performance boost (because Writer no needs to compile again and again new formatting directives).
You may not have notice progressive performance degradation if you don’t update frequently your machines. For example, my computer is already at kernel 6.14.9, KDE 6.14.0, Qt 6.9.1 and LO 25.2.4.3.
I have highly sophisticated technical documents in the 300-500 pages without problems on a now ageing computer. But I follow a very strict semantic styling method.
This is one of the equivocal terms in LO microcosm.
For laymen, a “template” is simply an example document to be copied as a starting state for a new one.
In LO parlance, a template is a special document, with extension .ott, containing styles and initial text. When you start a new document from a template, there is no need to copy first the template because it is protected against overwriting. It automatically creates an Untitled.odt targeted into your default documents directory. The new document remains linked to the template, so that changes in the styles of the template file are forwarded to the dependent documents when you later open them. Template and documents remains in sync, benefiting from your style tuning.
Changes to initial text are never forwarded because this could result in data loss. I use initial contents in my templates to provide a full document “skeleton” with cover page, legalese, front material, TOC, one empty chapter, alphabetical index. It is easier and more reliable to erase data than to add recurrent text without error.
