Bug 106918 - Sections with two columns have to be deleted then un-deleted to display correctly
Summary: Sections with two columns have to be deleted then un-deleted to display corre...
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.2.5.1 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Section
  Show dependency treegraph
 
Reported: 2017-04-02 19:37 UTC by ammine007
Modified: 2018-01-29 10:36 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Document with the issues I described, version 5c. (648.99 KB, application/vnd.oasis.opendocument.text)
2017-04-29 05:15 UTC, r@fael.lv
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ammine007 2017-04-02 19:37:26 UTC
Salamu alaikum,

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!

Version: 5.2.5.1
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
Comment 1 Xisco Faulí 2017-04-03 12:01:08 UTC Comment hidden (obsolete)
Comment 2 r@fael.lv 2017-04-29 05:15:20 UTC
Created attachment 132947 [details]
Document with the issues I described, version 5c.
Comment 3 r@fael.lv 2017-04-29 05:39:11 UTC
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 5.2.6.2, 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. 

Issues: 
- 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.
Comment 4 r@fael.lv 2017-04-29 05:46:53 UTC
Additional information: I'm working on Windows 8 and 10, 64 bit, Writer 5.2.6.2.
Comment 5 Buovjaga 2017-04-29 18:00:27 UTC
A minimal document would be much better. ammine007: still waiting for your document.
Comment 6 r@fael.lv 2017-05-05 12:51:51 UTC
(In reply to Buovjaga from comment #5)
> A minimal document would be much better. ammine007: still waiting for your
> document.

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.
Comment 7 QA Administrators 2018-01-02 10:15:24 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2018-01-29 10:36:26 UTC
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

Warm Regards,
QA Team

MassPing-NeedInfo-20180129