Description: Hi! A sample of a document (for an examination) is attached, that document already has two questions. If you use Word you can "copy" the first question and insert it between the first and the second ones. However, if you try to do the same using Libreoffice Writer: the result is unexpected and you have to make too many changes to the "pasted" question; you can't even "clone formatting" to try to solve the problem intuitively. I'm sure that this problem will happen in other cases. Thanks for Writer! Steps to Reproduce: 1. Open the attached document. 2. The attached document already has two questions. You can try "copying" the first question and insert it between the first and the second ones. Actual Results: The pasted question (and its possible answers) have a wrong format. Expected Results: The pasted question (and its possible answers) should have the same format as it had. Reproducible: Always User Profile Reset: Yes Additional Info: User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Created attachment 129967 [details] The forementioned sample document (the examination template)
About the actual results: The pasted question (and its possible answers) have a wrong format. and also Users can't even "clone formatting" to try to solve the problem intuitively.
Created attachment 129969 [details] The expected result
Created attachment 129970 [details] The obtained result Also, users can't even "clone formatting" to try to solve the problem intuitively.
On pc Debian x86-64 with LO Debian package 5.2.4, I don't reproduce this if I select from "1. Which" line to the line after g) included, copy it and paste it in this same line.
It depends on which part is marked for copying. From end of line before "1. Which [...]" to end of line "g) [...]" works. From immediately before "Which" to line after ""g) [...]" works too. But from immediately before "Which" to end of line "g) [...]" does not work. BTW, is it intended, that 1. 2. … is a different list than a) b) c) …?
> BTW, is it intended, that 1. 2. … is a different list than a) b) c) …? Let's say that in an examination you can have 10 questions [1. 2. 3. 4. … ] and question 1 can have several options [ a) b) c) ], question 2 can have its options [ a) b) c) ] [not d) e) f) ], question 3 has its options [ a) b) c) ], etc.
Thanks, Julien and Regina. So one key is the "to the line after g) included" specification that Julien wrote, if we do exactly that... then the problem doesn't appear :-) The problem appears e.g. if (before copying) the user selects until the end of the line that starts with the g), but not selecting until the next line (the one that is empty); later, after pasting: "clone formatting" doesn't solve the problem, etc. Somehow Word works correctly doing that, but not Writer (our preferred :-)). Anyway, something like workarounds were written by Julien and Regina! Even when this problem is not still solved, and users see it, at least people can work meanwhile :-)
Created attachment 133039 [details] A second case -- similar problems when inserting questions (for example copying a question to the place between the second and the third question) There's a related case, I attach an example. When using a document for creating examinations... there are important problems when inserting questions (for example copying a question to the place between the second and the third question). None of the workarounds described previously seems to work. I'll attach some screenshots. However, Word is able to do that as it was expected (although it's not free/libre software :-) so it's not really comparable ). Thanks!
Created attachment 133040 [details] In the second case: the expected result
Created attachment 133041 [details] In the second case: the obtained result
(In reply to Ganton from comment #8) > Thanks, Julien and Regina. > > So one key is the "to the line after g) included" specification that Julien > wrote, if we do exactly that... then the problem doesn't appear :-) The problem that the selectables in the new second question start with h) is something that I cannot work around no matter how I copy&paste. Yet, this can be fixed by right-click the list and selecting Restart numbering. Then they start with a). Regarding the second case in comment 9, I think it would be good ask in https://ask.libreoffice.org/en/questions/ I'm not a guru with lists, so I don't have an insight of a best practice. Win 7 Pro 64-bit Version: 6.0.0.0.alpha0+ (x64) Build ID: bec5a2ac82b5178f6e765494c2003febe8ab51da CPU threads: 4; OS: Windows 6.1; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-08-12_23:35:00 Locale: fi-FI (fi_FI); Calc: CL
Thank you for reporting the bug. I can confirm that the bug is present in: Version: 6.0.4.2 (x64) Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: CL
(In reply to Buovjaga from comment #12) > (In reply to Ganton from comment #8) > > Thanks, Julien and Regina. > > > > So one key is the "to the line after g) included" specification that Julien > > wrote, if we do exactly that... then the problem doesn't appear :-) > > The problem that the selectables in the new second question start with h) is > something that I cannot work around no matter how I copy&paste. > > Yet, this can be fixed by right-click the list and selecting Restart > numbering. Then they start with a). I'm wondering, is it the expected behaviour? MSO 2010 seems to behave the same way...
Hello, I've tried it again, using MS Office 2016 and the document of the attachment 133039 [details], and there the fundamental problem wasn't seen (the result was more like the attachment 133040 [details] than like the attachment 133041 [details]).
Dear Ganton, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The bug is still present in Libreoffice 6.2.3.2.
Attachment 129967 [details] was explained in comment 6, I don't see it as a bug. Remaining is (Lo created Docx) attachment 133039 [details]. Lo 7.2+.
Oh my - these are in DOC/DOCX format - which just complicates matters even more.
> Attachment 129967 [details] was explained in comment 6, I don't see it as a bug. If the problem of the second file is solved... it would be good that the problem of the first file would be solved, too, since we can not expect users to follow a particular method to select lines (any method works using for example MS Office 2016).
Created attachment 171765 [details] The forementioned sample document (the examination template) - ODT version
Created attachment 171766 [details] A second case -- similar problems when inserting questions (for example copying a question to the place between the second and the third question) - ODT version
> Oh my - these are in DOC/DOCX format - which just complicates matters even more. After saving the files as .odt: problems are seen when reproducing the tests. No problems are seen when using MS Office with the odt files.
(In reply to Ganton from comment #23) > After saving the files as .odt: A DOC* file then saved as ODT is still basically a DOC file since all the compatibility settings still exist. A true ODT file is one that has only ever been ODT.
Created attachment 171769 [details] The forementioned sample document (the examination template) - similar ODT though built from zero
Created attachment 171770 [details] A second case -- similar problems when inserting questions (for example copying a question to the place between the second and the third question) - similar ODT though built from zero
Created attachment 171789 [details] 104945_testScenarios.odt: the document I was testing my patch on. I tried to make a patch, but what I have will cause regressions. As a code-pointer, it can be found at https://gerrit.libreoffice.org/c/core/+/115261.
*** Bug 64828 has been marked as a duplicate of this bug. ***
Thanks for caring, Justin. I've removed the "docx" from the title of the bug since it also happens to odt files. Feel free to change that. Greetings.
Created attachment 173051 [details] 104945_patch.diff: the patch which I don't dare to submit
Dear Ganton, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The bug still exists using Libreoffice 7.5.4.2