I'm using Libreoffice Writer to write a report. The problem concerns two-columns texts. Each time I'm obliged to delete a two-columned section then un-delete it, to display it and export it as a PDF correctly. Otherwise, It won't display as intended and the exported PDF contains a problematic two -columned section.
As a work around, I have to delete each two-columned section and un-delete it, then re-do this operation to all 2cols sections sequentially.
Wi a report containing 17 2cols sections, it is counter productive and LibreOffice Writer is just unusable.
Thank you all!
Build ID: 1:5.2.5-2
CPU Threads: 4; OS Version: Linux 4.9; UI Render: default; VCL: gtk3;
Locale: en-US (fr_FR.UTF-8); Calc: group
On Debian 64bits
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive information before attaching it.
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Created attachment 132947 [details]
Document with the issues I described, version 5c.
I came to file a bug about what I think is the same issue described by @ammine007. Because I have a much more complex document, it might be related to a different bug, or many different bugs, previously reported here or no.
I'll try to be objective, but have in mind this could come from more than one source. I am submitting the document where you can verify the issues related. The document is my original (no problem with that), with the images compressed into oblivion, turning a 15mb document into 650kb.
Writer Versions: I've been verifying this problem for several months, or ever since I started writing a large document (from at least June 2016). Now I am on 22.214.171.124, problem can still be verified. Also have in mind, I am using Writer in pt-br, which makes it a little harder for me to tell you the english names of options, but I try.
Context: I have a two-column document with several pages (200+), and in some pages I change it to one-column (for chapter titles), then two-column again. It also has pictures, tables, boxes, alphabetical index, summary, empty pages, etc.
- Position of elements (sections, tables, pictures with certain alignments) changes randomly. Sections that should be tightly together break to a new page, then while editing a section several pages further into the document, they tie together again.
- If I preview print, position of sections and pictures change, number of pages change.
- If I update alphabetical index, many things change positions, if then I update the opening index of titles, things go to another different position.
- If I go to Format > Columns and change the setting "Distribute content evenly across columns", nothing changes, until I insert a line break in the end of a section, but after a while it displays differently at random. For example, I tell it to distribute evenly, so it should display the columns on the last page of that section roughly of the same size, leaving some space for the next section in the same page. Instead, it fills left column all the way to the end of the page and leave right column with only a few words, mostly empty, next section is sent to the next page. Inserting a line break sometimes fixes that, but it goes back to wrong when I update indexes.
- When I open the document, page count is always wrong. Right now document submitted has 200 pages, but when I open it it says 203.
- Here's the worst part. If I go to Tools > Update > All, everything goes to its right place... except the opening index (the one that is dinamically updated by adding titles) gets page numbers wrong by 1 or 2 over the course of the document. If I then update again only that index, the document changes enough to break (positions go wrong again), but that index then gets the pages right though. It doesn't help, because it's the right page numbers with elements messed in the wrong positions.
How to verify issues:
- Open document attached. Note page count.
- Go to Tools > Update > All. Note page count change. It is now the right page count.
- Check the index in the last 3-4 pages, test if it gets one or two references right. That index is always right in my tests, at least right after the update.
- Check the index in page 3. Page numbers will be off by 1 or 2 pages from page 50 on, give or take. The last title which is the alphabetical index from page 197 is marked as being in page 199. If you update this wrong index isolatedly, it messes the document's total page count, messes positions of sections at random, but gets the page numbers right (from a messed document).
Workaround tried: I thought this could be a memory issue because it's a slightly large document (it's 15mb, but I noticed this happens since around 5mb). I changed memory limits in Preferences to larger and larger numbers. That did nothing that I could notice.
Workaround: Tools > Update > Update All does fix the document as intended, except for the index in page 3, the one that is dinamically created by titles in the document. So it's an incomplete workaround.
Workaround not tried: OP @ammine007 suggested that deleting and undeleting sections makes them behave correctly. That is impractical, obviously. I have many times inserted and deleted line breaks before sections and that had a similar effect of pulling the following section to its right place, but that is impractical in the same amount. If I do that over the whole document, when I update the indexes everything gets messed up again.
Additional information: I'm working on Windows 8 and 10, 64 bit, Writer 126.96.36.199.
A minimal document would be much better. ammine007: still waiting for your document.
(In reply to Buovjaga from comment #5)
> A minimal document would be much better. ammine007: still waiting for your
Though this might seem unlikely, these positioning issues aren't easy to reproduce with minimal documents. Either way apparently the OP has given up following up.
Dear Bug Submitter,
This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!
Dear Bug Submitter,
Please read this message in its entirety before proceeding.
Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):
a) Provide details of your system including your operating
system and the latest version of LibreOffice that you have
confirmed the bug to be present
b) Provide easy to reproduce steps – the simpler the better
c) Provide any test case(s) which will help us confirm the problem
d) Provide screenshots of the problem if you think it might help
e) Read all comments and provide any requested information
Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:
a) respond via email
b) update the version field in the bug or any of the other details
on the top section of our bug tracker