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
No point in reporting "Reproducible: Sometimes". Please write Reproducible Steps with attached document.
Dear DM, 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: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO 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! Warm Regards, QA Team MassPing-NeedInfo-Ping
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
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.
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
Please see two attachments uploaded with their comments. d
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 :)
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
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).
[Automated Action] NeedInfo-To-Unconfirmed
(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.
Dear DM, 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-FollowUp