Created attachment 58634 [details] File with distorted styles I assign a style to a paragraph, mark the paragraph and apply "Ctrl + M" (thus clearing direct formatting) and save the file. After opening the file all styles have been substituted by the "Default" style. See the attached files.
Created attachment 58635 [details] File before distorting styles
I can't reproduce the problem, but the report is much to rare. @jmkopy@gmx.net Please contribute a precise step by step instruction containing every mouse click and every key press.
ONLY with this file I can reproduce on LibreOffice 3.5.1 and OOo-dev 3.4. Two confident folks from OOo.org forum have tried with equals results. Only with this file have found the problem.
Does the bug occur when your document has only one paragraph?
I have to describe exactly how it happens: I mark the whole document: Ctrl + A (one paragraph marked) Ctrl + A (all paragraphs marked, or the whole document for that matter) Ctrl + M (clearing direct formatting) Saving the document Closing the document Opening the document --> All assigned styles are removed. When I do mark only one paragraph and apply the steps mentioned above then the same happens only for the tackled paragraph. See the new attached files.
Created attachment 59015 [details] Another file before styles are distorted
Created attachment 59016 [details] Another file after styles are distorted
Created attachment 59017 [details] Another file after style is distorted for one paragraph
(In reply to comment #4) > Does the bug occur when your document has only one paragraph? I tried it, the bug does occur once. When I assign a style again and repeat the steps mentioned above the styles are retained. The same is true for many paragraphs document. Actually it is true also for the attached documents above. Well, it looks that after a second "round" of assigning the styles the problem is almost gone. Having a long document it is a "nice" job to reassign the styles again. Having many documents it is even "nicer" so. I tried it again, with one of the above files. And some styles are persistently being removed and some remain. Hmmm? Even after reassigning the the styles many times.
I saved 3-th attachment as fodt and viewed as text. And found there this line: <style:style style:name="_5f_Heading_5f_00" style:display-name="_Heading_00" It means that style's internal name is different from name we see. I can not produce such style by my own. IMHO LibreOffice can not deal with such styles correctly. How to produced this document? May be from template that already has such corruption. Or by opening file, created by another program? Or copy-pasting.
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 INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/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
reproduced in 4.0.3 on Fedora (RFR) 64 bit using 3-th attachment (Another_file_before_distorting_styles.odt) and steps from comment 5
Could it be this bug is the same as https://bugs.freedesktop.org/show_bug.cgi?id=73411 ? Haven't found this bug before, but the loosing of styles has something to do with numbering and bullet, so I searched for bullets and found nothing.
IMHO bug is the same I just tried my idea from comment 10 on attachment from Bug 73411. I saved it as fodt format and manually removed style:display-name . But it not helps. Bug still reproducible. Therefore style:display-name is not a source of problem.
See also bug #61956, which might be a duplicate of this one.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.0.1 or preferably 5.0.2.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-10-14
*** Bug 95752 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
I can reproduce this bug with attachment 59017 [details] and with my own test file. Version: 5.3.2.2 Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1 CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; Locale: de-DE (de_DE); Calc: CL Steps to reproduce: 1. Create a Writer file. 2. Write some text. 3. Apply a paragraph style to the whole text (different than "Default style", e.g. Ctrl + A and select "Text Body"). 4. Select some text and do some direct PARAGRAPH formatting (e.g. open context menu "Paragraph..." > Area > Color > select red color > OK -- applying a yellow highlight color from the toolbar is not enough). 5. Select all text with Ctrl + A. 6. Type Ctrl + M. 7. Save the file. 8. Open the file again. Actual result: The text which was changed with direct formatting is assigned to "Default style". Expected result: Styles shouldn't change. My assumption: When changing text with direct formatting, LibO creates a new style in the content.xml (P1, P2, etc for paragraphs; T1, T2, etc. for character styles). This new style includes the direct formatting (e.g. background color) and a link to the parent style. When activating the "Clear Direct Formatting" command, LibO deletes the direct formatting. But LibO doesn't delete the new style (e.g. P1) completely AND doesn't assign the original parent style to the text. Example of content.xml before doing Clear Direct Formatting: <office:automatic-styles> <style:style style:name="P1" style:parent-style-name="Endnote" style:family="paragraph"> <loext:graphic-properties draw:fill-color="#ff0000" draw:fill="solid"/> <style:paragraph-properties style:writing-mode="page" fo:background-color="#ff0000"/> </style:style> </office:automatic-styles> <office:body> <office:text> <text:p text:style-name="Endnote">Ich bin ein Text.</text:p> <text:p text:style-name="P1">Ich bin ein Text.</text:p> <text:p text:style-name="Endnote">Ich bin ein Text.</text:p> </office:text> </office:body> Example of content.xml after doing Clear Direct Formatting: <office:automatic-styles> <style:style style:name="P1" style:family="paragraph"> <loext:graphic-properties draw:fill-color="#ff0000" draw:fill="solid"/> <style:paragraph-properties style:writing-mode="page" fo:background-color="#ff0000"/> </style:style> </office:automatic-styles> <office:body> <office:text> <text:p text:style-name="Endnote">Ich bin ein Text.</text:p> <text:p>Ich bin ein Text.</text:p> <text:p text:style-name="Endnote">Ich bin ein Text.</text:p> </office:text> </office:body> Suggestion: When activating the "Clear Direct Formatting" command, LibO should assign the parent style to the paragraph (in the example above: text:style-name="Endnote" instead of text:style-name="P1") and then LibO should delete P1 as much as it includes direct formatting.
So this is a regression introduce in 3.5 as not present in 3.4. Lets see if it can be bibisected.
(In reply to Yousuf Philips (jay) from comment #20) > So this is a regression introduce in 3.5 as not present in 3.4. Lets see if > it can be bibisected. I do not get such results. The last good version for me is Version: 4.4.0.0.alpha0+ Build ID: aa453de65b8b44f9c1e6012caaeef11df9ff65fc TinderBox: Win-x86@39, Branch:master, Time: 2014-05-24_13:45:34 The first bad version is Version: 4.4.0.0.alpha0+ Build ID: 86a3fe47a66950e26d23d7d7f2680fa7d4fb0839 TinderBox: Win-x86@39, Branch:master, Time: 2014-10-05_02:45:20 I haven't got versions between to test.
(In reply to Regina Henschel from comment #21) > I do not get such results. Not sure how i got those results as well. > The last good version for me is Version: 4.4.0.0.alpha0+ > Build ID: aa453de65b8b44f9c1e6012caaeef11df9ff65fc > TinderBox: Win-x86@39, Branch:master, Time: 2014-05-24_13:45:34 > > The first bad version is Version: 4.4.0.0.alpha0+ > Build ID: 86a3fe47a66950e26d23d7d7f2680fa7d4fb0839 > TinderBox: Win-x86@39, Branch:master, Time: 2014-10-05_02:45:20 > > I haven't got versions between to test. If this is where the regression happened, then it must be like the bug i just filed, bug 108248.
I think, it is the same.
With attachment 58635 [details], the losing of styles happens already with LibreOffice 3.3.0. Same with attachment 59017 [details] Even bug 73411 which is said to be a dupe of this is "Inherited". Arch Linux 64-bit LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
*** Bug 104988 has been marked as a duplicate of this bug. ***
*** Bug 111002 has been marked as a duplicate of this bug. ***
For more examples and steps to reproduce see the other issues bug 111002 and bug 104988.
Reproducible in recent 6.2.0.0.alpha1 build.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/7934d9085eeaf5903fee494195ed2d0c6fb74fbb%5E%21 related tdf#47471 textframe: use stylename if autostyle missing It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
easy fix proposed at https://gerrit.libreoffice.org/65616. A couple of related areas will have the same fix applied. Those will land earlier than the main fix because the unit test verification document is shared with bug 99573.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/fa1354861fffa69da2a1d1613f979f2f26242d24%5E%21 related tdf#47471 textgraphic: use stylename if autostyle missing It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/43836a58ffe943e2fc65be638f9a7d343102cb07%5E%21 tdf#47471 odfexport: use stylename if autostyle missing. It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Solved. Verified on Version: 6.3.0.0.alpha0+ Build ID: be8897d9c63a77b223a9c0aed1d2eb689e0e0082 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-01-02_04:49:04 Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US Calc: threaded
*** Bug 73411 has been marked as a duplicate of this bug. ***
Thank you very, very much, Justin Luth, for fixing this!
*** Bug 92352 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 73483 ***