Created attachment 191568 [details] Example of violation of formatting style precedence rule Version: 7.6.4.1 (X86_64) Build ID: 60(Build:1) CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb) Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded This is a follow up to https://ask.libreoffice.org/t/direct-formatting-of-list-symbols/99731 User asked for a way to individualise list item number. Colour for item text can be set with a character style or direct formatting. When you try to apply a character style on an item/number, this does not work or replaces the character style specified in the list style. Therefore direct formatting must be applied on the target item numbers. I found a selection method to designate the number as the target of the operation (without impacting item text). But, as long as the list style has a character style to format the number/bullet, direct formatting has no effect, at least for colour. After careful experiment, I discovered that the traditional precedence DF > CS is still valid for all character attributes, except colour where CS > DF. Colouring individual numbers/bullets is only possible if list style character style parameter in [None]. Please restore the common precedence rule DF > CS also for colour. May be related to bug 150517
Update to description of problem: My present workaround to apply some direct formatting to the number (and exclusively to the number, not impacting item text) is to select the paragraph mark of the target item. This works only if _Character style_ for this level is set to _None_. But, after more experimentation, I discovered that _Bullet_ "numbers" will not react to the workaround, making impossible to individualise an item bullet. _Graphics_ "numbers" also don't react but this can be expected. All other "numbers" can receive direct formatting (again, only if character style is None, which is a divergence from the usual precedence CS < DF for all other attributes)
Another addition to the issue: The direct formatting trick is either impossible or does not survive the session if the list item contains line breaks or cross-references (this seems irrelevant, but as soon as the list item is "complex", the trick is ineffective).
NOTE. The formatting add to list numbers isn't visible in older versions of LibreOffice. Like Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 30a048cb895a3dcdd6048f3c525edd95a1371b91 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL or Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL
Direct formatting bypassing list bullets or numbers is expected, for when the user selects several paragraphs at once (the bullets/numbers being inside the selection) and changing the direct formatting. I think most users would expect this to only affect the text and not the bullets/numbers. Regardless, you are here talking about a case when the selection only includes the bullet. I can see your method in https://ask.libreoffice.org/t/direct-formatting-of-list-symbols/99731/7 requires the user to have a selection of _the next_ bullet/number in order to change the direct formatting of a bullet/number. The first thing to do is sort out this oddity of having to select a different thing to what we want to change, in bug 158879. Anyway, reproduced in recent trunk build: changing the marker's character style from "Numbering Symbols" to "None" in the sample's 3rd list restores the green colour.
(In reply to Stéphane Guillou (stragu) from comment #4) > Regardless, you are here talking about a case when the selection only > includes the bullet. I can see your method in > https://ask.libreoffice.org/t/direct-formatting-of-list-symbols/99731/7 > requires the user to have a selection of _the next_ bullet/number in order > to change the direct formatting of a bullet/number. > The first thing to do is sort out this oddity of having to select a > different thing to what we want to change, in bug 158879. After thinking about it, it is not that odd. What you select in fact is the paragraph marker. It belongs in the current list item (it is the last "component" of the paragraph). Therefore, "logically", you are still inside the list item you want to change, even if you select something "at the other end". What is confusing (even for somebody versed in Writer subtleties), is teh necessity to select also the next list number (which does not happen when you want to process the last item in a list because the next paragraph is "normal"; it also means you must create an extra paragraph if the list item is the last paragraph in a document) because the list number is a Writer-generated piece, not something explicitly entered by user. And this gives the illusion you select something in the next paragraph. > Anyway, reproduced in recent trunk build: changing the marker's character > style from "Numbering Symbols" to "None" in the sample's 3rd list restores > the green colour. This is where the bug lies. DF precedence over character style is observed for all attributes, except colour. This means you can't play with both character style and DF for spot modification. This breaks the usual behaviour PS < CS < DF. This precedence should be restored for colour and afterwards we'll evaluate to see if this solves the problem without introducing others. I think the request is rather exceptional that most users won't ever be aware of the possibility. So, the selection peculiarity could be left aside it too difficult to improve.