Created attachment 176846 [details] File that has changed from LibreOffice 7.1 to 7.2 After upgrading to LibreOffice 7.2, the color of my list numbering in some files has changed its color, and I can't change it back. The attached file is a Physics problem sheet for my students. Up until LibreOffice 7.1 (and at least as far back as LO 5.x), it has looked the same: every font is black (including list numbering and bullet points), except for the solutions, which are presented in blue. After upgrading to 7.2, some list numbers have become blue too, and I can't change them back to black. This includes problem number 3 (but not the others), and sections a, b, c, d of some of the other problems. So in summary: if the attached file is opened with LO 7.1 or older, it looks as intended; whereas in LO 7.2 some colors have changed, and I can't fix them. Just in case, I'm attaching PDFs of how the sheet is supposed to look (LO 7.1 and newer) and how it looks in 7.2.
I forgot to clarify that this isn't a single occurrence. All the problem sheets that I use for my classes have experienced the same color changes, at certain degree.
Created attachment 176847 [details] PDF file of how the sheet is supposed to look (i.e. how it looked before 7.2)
Created attachment 176848 [details] PDF file of how the sheet looks after 7.2, with some list numbers and letters changed to blue
I confirm it with Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: deea3b7471c3dab0220eca6146c225a2d47681a2 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL but not with Version: 6.3.6.2 (x64) Build-ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: CL Could not figure out, what causes the different colours. Character Style of first list in "Numbering Symbols". When I modify font colour of this style from automatic to black, colour changes. but I don't know, why "automatic" results in a blue colour. If you create a new list, problem doesn#t appear.
Thank you for confirming it, Dieter. After fighting with this bug for a while, I have a couple of comments: - The list numbers' and letters' color is somehow matching the color of the last character of each paragraph. For example, in exercise 1 section d, the last character is a blue L (from "[C2] = L"). If you change the color of that L to green and click somewhere outside the list, the "d)" will become green too. Clicking outside the list is important: if you remain in any paragraph that belongs to a list, the "d)" remains in the old color, but as soon as you click on a paragraph that doesn't belong to a list (for example, the sheet title or any of the empty lines between exercises), the color of the "d)" is changed. - You say that you can modify the color when you change from automatic to black, but I think that only works once. Let me explain myself: 1. Go to exercise 1, section a. Put the cursor on the "a)", click on the "font color" icon, and select some other color. It works. 2. Now try to do exactly the same thing again (in the same list, or another one). This time, for some reason the mouse pointer becomes into the one that appears when you want to clone format (sorry I don't know how it's called), but the color change doesn't work. The trick I explained in my first point (changing the color of the last character) stops working too. This all seems so random. I hope someone can figure it out, because making all my problem sheets from scratch is going to take many hours. Thanks!
This seems to have begun at the below commit. Adding Cc: to Justin Luth ; Could you possibly take a look at this one? Thanks 0ecb686a9b7b69dfb5f0b8e0d0cad482efda8f63 is the first bad commit commit 0ecb686a9b7b69dfb5f0b8e0d0cad482efda8f63 Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Mar 18 19:45:16 2021 +0100 source 0a32371cc2f93fad7954e0fe9c48976aae6c5b9f https://git.libreoffice.org/core/+/0a32371cc2f93fad7954e0fe9c48976aae6c5b9f
This is basically a duplicate of bug 150613. This file must have spent part of its life as a Microsoft format. This has the setting ApplyParagraphMarkFormatToNumbering = true, which was a (poor) way to handle Microsoft's ability to apply carriage-return formatting to the numbering. Well, LO doesn't have the ability to format a carriage return - and thus the compatibility flag. I expect this will just need to be worked around. Some suggestions: 1.) save as DOCX (or DOC) since those formats now have improved abilities to deal with this, and basically now avoid this section of code. 2.) Select the whole document (Ctrl-A) and copy/paste into a new document. 3.) unzip the ODT, and change (or delete) settings.xml's ApplyParagraphMarkFormatToNumbering. (This could probably be scripted, although there is some trickery about "properly" zipping up an ODT file.) I don't think we can adapt the code to do something like #1's fix for isODT - because those all have to do with compatibility settings, and I'm not aware of ODT loading any flags that wouldn't apply to importing an MS Format. (In fact, this is the only place in the SW code that we have an "IsDOCX" variable.)
We have been battling these kinds of things for years in DOC and DOCX formats, so having partial remnants of ms format compatibility flags in your documents going to cause you problems. P.S. It should be sufficient to round-trip once as DOCX to pick up the latest compat flags and then you could save back again into ODT format if you prefer using the native file format.
Thank you for the explanations, Justin. I can confirm that making the round-trip ODT -> DOCX -> ODT does, indeed, fix the issue. The thing I don't understand is that I'm almost 100% positive these files have never been in a MS format before. I created them from scratch in LibreOffice on Linux in 2017, I don't even have MS Office. But anyway, I'm happy with the workaround.
(In reply to David de Cos from comment #9) > The thing I don't understand is that I'm almost 100% positive these files > have never been in a MS format before. That sounds like the response in the related bug too. I just now tried to search in the code to see if perhaps it did default to true for ODT at some point, but I couldn't find any evidence of that. Perhaps a built-in LO template had that setting, and you started from a template? (However, although our templates have had weird settings in them, I don't see any evidence of this particular setting either.) Example's created by people making unit tests in .fodt format only shows a single entry that has ApplyParagraphMark... set to true and that was created in 2023 related to MS Word compatibility. Spot-checking a few examples from 2015 and 2018 were all "false". So almost certainly something in the past triggered this, but I'm not sure where else to chase this. I hope not too many people run into the problem you had.
Well, you might be right after all. I started as a teacher in 2016, so I just opened the first work sheet I created back then, and in the Properties section it says it was created in 2009. So I must have based it on someone else's previous document. I could have sworn I did it from scratch, but apparently I didn't. Than you very much for your help, and sorry for making you double check things when you were right the first time!
(In reply to David de Cos from comment #11) > Than you very much for your help No problem. Thanks for reporting. This is a coding-disaster area, so double-checking never hurts anything. marking as WONTFIX since in the targeted case (.RTF) this still is needed and the document in question has RTF-comparable compatibility flags.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/27df5ef405826875340645b9b979bd5c2c0b92cc tdf#146168 tdf#150613 list attributes: limit hack to RTF It will be available in 7.6.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 "libreoffice-7-5": https://git.libreoffice.org/core/commit/729ebba19d9a3d7a1de24654366e0517e30a999e tdf#146168 tdf#150613 list attributes: limit hack to RTF It will be available in 7.5.2. 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.
*** Bug 153810 has been marked as a duplicate of this bug. ***
VERIFIED with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 006b35d50024b1932d84380b5d2fec1f7066bccd CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (de_DE); UI: en-GB Calc: CL threaded Justin, thanks for fixing it!