The problem seems to occur randomly when the chosen index entry is different from the actual word(s) in the text. A switch to italics or bold is sometimes triggered and may continue for several words or even lines. This is real, not a view artefact. It survives exporting the page to pdf. The unwanted styling can be removed by using the bold or italic button (but not by "Clear direct formatting"). However, when the document is filed and reopened, the unwanted styling comes back, always in the same places. If I delete the index entry, the unwanted styling disappears. The document was created in LO 4.0, but the problem persists when I open it in LO 3.5.
Created attachment 85875 [details] one word in italic make paragraph bad
Created attachment 85924 [details] Document showing the wrong behaviour Hazel sent me a sample document allowing to reproduce the bug. I use version 4.1.2.1 and confirm the problem with italic and bold triggered in the text. Sophie
Lowering the priority (no data loss, workaround) and set the bug to new - Sophie
(In reply to comment #1) > Created attachment 85875 [details] > one word in italic make paragraph bad Andrey, your attachment doesn't show the problem exposed by Hazel. If this is another problem, please fill another issue. Sophie
(In reply to comment #2) > Hazel sent me a sample document allowing to reproduce the bug. I use version > 4.1.2.1 and confirm the problem with italic and bold triggered in the text. There appears to be extensive use of overriding formatting (paragraph style > character style > direct formatting) in that attachment. The document may therefore not be the best example, although it /may/ still be an issue. I am not clear on what is expected behaviour given this type of formatting. To be clear, the italic issue is displayed on the 1st page in the 4th paragraph beginning "The widespread occurrence ..." and the bold issue is displayed on the 2nd page in the 2nd paragraph beginning "The simplest desktops ...". Opening the ODT with an archive manager and examining the XML I can see these style entries (styles.xml): <style:style style:name="Emphasis" style:family="text"> <style:text-properties fo:font-style="italic" style:font-style-asian="italic" style:font-style-complex="italic"/> </style:style> <style:style style:name="file" style:family="text"> <style:text-properties fo:font-weight="bold" style:font-size-asian="10.5pt"/> </style:style> These are both character styles (for italic and bold respectively) and yet they have been applied to the entire text e.g., in content.xml the 1st paragraph on the 1st page is defined: <text:p text:style-name="Standard"> <text:span text:style-name="Emphasis"> <text:span text:style-name="T3">forces users to buy a new computer every time a new version comes out. That is certainly not what users want! Instead it’s very much what the computer manufacturers want, and Microsoft gives it to them to ensure that they will go on putting Windows onto every box they sell. Microsoft also frequently makes arbitrary and sweeping changes to the user interface, with little concern for whether users like it or not. Windows 8 is a particularly crass example. </text:span> </text:span> </text:p> The inner (T3) direct formatting is overriding the Emphasis character style, which in turn is overriding the Standard paragraph style. Where the two alphabetical marks appear these inner direct formatting elements (e.g., T3 in the example shown) are being lost and so the text is reverting to the character style in effect on that paragraph (either italic or bold) for the remainder of the text. "Clear direct formatting" does not remove character styling, so what Hazel describes makes sense.
I opened the attached ODT under Ubuntu 10.04 x86_64 using: - v3.3.0.4 OOO330m19 Build: 6 - v3.4.6.2 OOO340m1 Build: 602 - v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b - v3.6.7.2 Build ID: e183d5b - v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24 - v4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72 All versions exhibit the same existing visual change (i.e., reversion to italic/bold at the respective points indicated), which merely indicates they are all observing the underlying markup correctly. Arch/Platform set to All/All. Version left as-is because I have not tested the inserting behaviour.
** 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 (4.4.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-05-02
I have now tried this again in LO 4.4.1 and 4.4.2, running under Crux. I used the same document as before, and the bug seems to have been corrected. The procedure I used was: 1) clear the bad formatting by hand and save the document. 2) reload it; it was still correctly formatted and had not reverted. 3) exit LO, then start again and reload the document. Format still OK. 4) update the index and recheck. Format OK.