Bug Hunting Session
Bug 119369 - Repeat Table Heading Suddenly Appeared
Summary: Repeat Table Heading Suddenly Appeared
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.5.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
 
Reported: 2018-08-19 18:56 UTC by DM
Modified: 2019-09-15 05:09 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Repeatable Example (22.03 MB, application/vnd.oasis.opendocument.text)
2019-08-08 15:33 UTC, DM
Details
Repeatable Example of Table Pos Floating in Wrong Place (22.03 MB, application/vnd.oasis.opendocument.text)
2019-08-08 21:37 UTC, DM
Details
Sample Screenshot (Floating) (415.77 KB, image/png)
2019-08-08 21:55 UTC, DM
Details
Showing Tables Overlaying (22.03 MB, application/vnd.oasis.opendocument.text)
2019-08-08 22:26 UTC, DM
Details

Note You need to log in before you can comment on or make changes to this bug.
Description DM 2018-08-19 18:56:53 UTC
Description:
In one of my documents more than one of the tables have had their top rows spontaneously become 'repeat headings', appearing duplicated on the next page (you can alter the text in the first instance and the 'repeat' text is likewise altered).
I will attach an exhibit shortly when I have one in a minimal form.
Cheers, David

Steps to Reproduce:
-

Actual Results:
-

Expected Results:
-


Reproducible: Sometimes


User Profile Reset: No



Additional Info:
Version: 6.0.5.2 (x64)
Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16
CPU threads: 2; OS: Windows 10.0; UI render: default; 
Locale: en-GB (en_GB); Calc: group
Comment 1 Timur 2018-08-20 10:37:20 UTC
No point in reporting "Reproducible: Sometimes".
Please write Reproducible Steps with attached document.
Comment 2 QA Administrators 2019-08-03 03:06:43 UTC Comment hidden (obsolete)
Comment 3 DM 2019-08-08 15:33:33 UTC
Created attachment 153236 [details]
Repeatable Example

The attached example shows the problem in a repeatable way.
Go to p15 and delete the carriage returns above Holly Blue, save and reopen - you will find all the arrows and labels completely mangled. I found also in moving them back (or creating new ones) and resaving, they just jump back again but adding CR before that table makes them ok.
Much of the time they have not been repeatable, yet happen all the time, because you often only discover on reopening the document or when you look further down the document and find an impact.
This isn't the only problem. In general, I'm using pictures in table cells with drawing elements (arrows and text boxes) and they are constantly mangled by all sorts of processes - moving something somewhere else in the document (you discover later the mangling), moving the table (particularly cut and paste - dragging to a new place seems to be much much safer). It's far worse when you have a single table so I am using 1 or 2-row tables that are separate and this 'contains' the mangling to individual tables and allows reordering the tables by drag-and-drop without wrecking the drawing elements in the document so much. I have to take a PDF snapshot all the time, so I can check every day etc what gets mangled and fix it back. In terms of quality level the bug puts tables-with-drawing-objects as not fit for production, but I am using Libreoffice because it can export without quality loss, so I can put little insets which people can zoom into on a PDF program.

Version: 6.2.5.2 (x64)
Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
CPU threads: 2; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: en-GB (en_GB); UI-Language: en-GB
Calc: threaded
Comment 4 DM 2019-08-08 15:38:01 UTC
Other major issues with the above type of documents are with tables that find themself floating in the middle of a page with huge gaps from the prior text which they are meant to be adjacent to, which is often fixed by going to the text immediately above it (way above because of the gap) and adding a CR and it jumps back to its place. There may be a connection between these two bugs because both are very frequent and both seem to relate to an inability to get the right position. If I find a repeatable example of this, I will include it.
Comment 5 DM 2019-08-08 21:37:57 UTC
Created attachment 153245 [details]
Repeatable Example of Table Pos Floating in Wrong Place

In this second example, again repeatable, if you go to p4, you can see a random gap between header "Yellow" and the table that follows. Add a CR after the heading Yellow and remove the CR, it restores the floating table's position - now save it and reopen the document and the table has jumped away again with a huge gap.
As mentioned, I suspect the two phenomena may be related, in that where I have the one bug I tend to find the other also. d
Comment 6 DM 2019-08-08 21:38:58 UTC
Please see two attachments uploaded with their comments. d
Comment 7 DM 2019-08-08 21:46:25 UTC
On the table pos floating in the wrong place uploaded note on p10 the huge gap between the Northern Brown Argus table and the next table which falls on the next page. Negotiating these constant bugs is extremely taxing :)
Comment 8 DM 2019-08-08 21:55:12 UTC
Created attachment 153246 [details]
Sample Screenshot (Floating)

This is a sample screenshot of problem 2 which is being highlighted, with the red arrows pointing out the vast spaces appearing between tables that shouldn't be there, which when you remove reappear again, or reappear somewhere else in the document, either quickly, or when you next open. d
Comment 9 DM 2019-08-08 22:26:25 UTC
Created attachment 153247 [details]
Showing Tables Overlaying

In this example I've tried to fix the floating tables by removing all 'keep togethers' etc and positioning things manually with lots of CRs. You can see on p16 two separate tables are overlaying each other when they are separate (they should display one followed by the other).
Comment 10 QA Administrators 2019-08-19 07:09:32 UTC Comment hidden (obsolete)
Comment 11 Dieter Praas 2019-09-15 05:09:04 UTC
(In reply to DM from comment #3)
> Created attachment 153236 [details]
> Repeatable Example
> 
> The attached example shows the problem in a repeatable way.
> Go to p15 and delete the carriage returns above Holly Blue, save and reopen
> - you will find all the arrows and labels completely mangled. I found also
> in moving them back (or creating new ones) and resaving, they just jump back
> again but adding CR before that table makes them ok.

I can't confirm this with

Version: 6.4.0.0.alpha0+ (x64)
Build ID: f0c832acb53326ccc9a8c1a47401fbc9e1081feb
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-09-11_05:46:53
Locale: en-GB (de_DE); UI-Language: en-US
Calc: threaded

but in LO 6.2.6.2 I get a different layout.

So could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? or at least with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version. Change to RESOLVED WORKSFORME, if the problem went away.