Hi, I’m preparing the layout of a book in Hungarian in LibreOffice. After I typeset the text and make detailed adjustments, the text sometimes reflows when I reopen the file. What is the best way to prevent this from happening?
Could you share a document containing 2-3 pages which include the problem?
And don’t forget to mention OS name and exact LO version. We’ll see save format from the sample.
Hi there, here are the details:
Version: 25.8.1.1 (X86_64)
CPU threads: 4; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: hu-HU
Thanks!
I’m attaching a few pages where the text were reflowed.
UGORJ AZ ISMERETLENBE új_A5_tördelhető_Libre_O_to_send.odt (47.4 KB)
What was the initial state? What changed on open? What did you do to fix the situation and did not persist on reopen?
All I can tell for the moment is your document is entirely direct formatted. This makes it very sensitive to inadvertent changes. In addition you have a line break Shift+Enter instead of a paragraph break Enter after “befejeződött.” and before “A Maharsi” in page 2.
Using styles results in a more stable document.
Never, ever, save your documents with MSWord.
My advice: Save a copy of your document as .txt, open this copy with Writer, (side by side with the old one, to compare with) and apply styles.
Yes, this seems to be okay. But look at the same page in the document. I’ve attached a screenshot. And I haven’t done anything to it.
OK. What should I see? Note I haven’t installed hu_HU hyphenation package; consequently, line breaks are different here.
Also, yur screenshot was taken with View>Formatting Marks disabled. (You seem to have inserted soft hyphens in several words to tag your preferred hyphenation locations)
What is the problem? How would you like it to be fixed? Give a “literary” description.
The problem is that I completed the layout, including soft hyphens etc., but the next time I opened the file, the text was reflowed. So what I see on my screen when I do the layout is somehow not the final version. And that means a lot of work for nothing.
Please, don’t use Suggest a Solution for what is in fact only a comment. You might suggest to potential contributors that already several fixes have been provided and it is therefore pointless to read the question.
At this point, I still don’t know what is reflown (which words? which paragraphs?). I have no comparison reference. I can’t reproduce the issue because I don’t know what to look for.
What kind of layout adjustment do you apply to your text? Which does not persist across sessions?
According to the screenshot, your document is probably 433 pages long. Such a large document cannot be reliably formatted and laid out if you don’t practice styling. This is the only sensible advice for the moment.
OK, thanks.
Why not? I know the advantages of styles but usually I expect 2 points:
- The document may not be pretty formatted, but reflowing it on the same machine, with same conditions should give the same result as before.
- If I save to .odt I expect the same view of the document after reloading.
On this site it is often recommended to save as .odt But if this can not reload my document properly, the advice is useless. (By the way: Saving as .docx would have been my first guess for a changed re-flow.)
I also remember we had a new algorithm to re-flow/typeset paragraphs recently. This should not change on save/open, but maybe...
A bug here is hard to find, as hunting down this may include screenshots before safe and after reload and you may need to avoid save and always do save-as "new-filename" until you even have some place to inspect... But a not provoked changed re-flow is a bug.
The main problem here is to identify the cause of re-flow. I agree that no matter how you format your document it should be stable. However, I met a circumstance where I had a “long” table in a multi-column section which spread differently after re-open. I had to add an empty paragraph in the table and delete it immediately to restore the intended layout (I thought I had filed a bug report but I can’t retrieve it, so maybe I didn’t, being probably unable to create a small faulty sample file).
So the first task is to find the key part in the document. It is easier to pinpoint it under strict styling.
A silly idea comes to my mind. When you edit a document, backstage changes are made to it to “improve” change tracking. This tagging impacts document structure and contributes to size inflation without immediate added-value to the user. It is controlled by Tools>Options, LO Writer>Comparison, Random number to improve …. Try unticking Store it when changing the document. Unfortunately this does nothing to the existing tags.
Presently we still don’t know how the document looks when it is in “correct” shape and how the same sequence is re-flown differently.
Now I know what to look for, I can experiment.
However, I have two limitations:
- font Bookman Old Style is not available on my system, therefore the metrics used is not exactly the same;
- I don’t intend to install hyphenation package for hu-HU
This impacts the accuracy of the diagnostic. I cheated by forcing text language to one for which I have hyphenation rules. This is not ideal but enough to activate hyphenation.
I think I can suggest a track: hyphenation control.
I experimented with Text Flow property Hyphenation zone. It looks like your text is highly sensitive to this parameter. It controls the threshold between word hyphenation and inter-word linewrap. If I set it “sufficiently low”, I can hyphenate the text, not exactly at the same points but this allows to have an idea on how word spacing is modified.
But your text is entirely direct formatted and I cannot guarantee that adjusting Default Paragraph Style will fix the issue. I discovered a bug with this parameter (it can’t be reset to parent’s state). If direct formatting has touched this setting, you are doomed to modify each paragraph individually.
Nevertheless, this is not sufficient to explain the “glitch” when reopening the document. There may be a weird issue with integer arithmetic used in Writer. There could be an interaction between margin width internal measurement and hyphenation zone distance.
When you open the file, text is fully (initial) reflown. Then you touch something and the division operations don’t give the same remainder (this could impact only a few low-order bits), just enough to consider hyphenation should not occur.
My suggestion is:
- change (temporarily) your font to another one with a fundamentally different metrics; does it still happen?
- play with Hyphenation zone; does it still happen?
Maybe, you need to take a look at the xml code. This file was saved with Word.