Created attachment 187896 [details] A single list having items with different list styles Open the attached sample. With styles panel open on List Styles, check that the first, second, and fourth list items have style "ListStyleOne", and the third item has "ListStyleAnother". Note also, that the numbering of all four is contiguous (1., 2., 3., 4.). Save (as ODT or FODT) and reload. Since commit 8f48f91009caa86d896f247059874242ed18bf39 (version 7.4), the numbering is broken in the last item, which is now numbered "1." instead of expected "4.".
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/82bbf63582bdf28e7918e58ebf6657a9144bc9f3 tdf#155823: Improve the check if the list id is not required It will be available in 24.2.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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/32981c8c7a166eb7309a40bdd4799ad77fcd1615 tdf#155823: Improve the check if the list id is not required It will be available in 7.6.0.0.beta2. 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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/de8c8cea231a42a8e4fa9048606de1c41aae0821 tdf#155823: Improve the check if the list id is not required It will be available in 7.5.5. 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.
Hi Mike, Could you give me more information on how you created the sample file? In my mind-model of list numbering, I don't understand why "Item 3(ListStyleAnother)" is numbered 3. and not 1. (and subsequently why the last item is numbered 4. and not 3.). May it be an artefact of direct formatting? When the document is reloaded, it is scanned for an initial display. Writer sees a level-1 list identified by ListStyleOne, followed by a level-1 list ListStyleAnother. Then it meets again a level-1 list ListStyleOne. It may legitimately assume that since there was another independent level-1 list in between, this is a new instance of ListStyleOne and restarts numbering (this behaviour may be debated but this is a rather pragmatic one). IMHO, the bug in the sample document is to number 3. the ListOneAnother item instead of 1. because this item references another list style which can't be synchronised in any way with another list style. And this "invalid" 3. number survives save and reload. I'd like to understand how ListStyleAnother continues numbering of ListStyleOne without a manual restart ! Analysis done with 7.5.3.2, Fedora 38 (Linux 6.3), KDE Plasma desktop
(In reply to ajlittoz from comment #4) This example is, indeed, a manually constructed markup, to extract the essence of a customer problem. To be honest, when I started to work on this, I was surprised as well. It turns out, that being able to join different styled lists into a single discontinuous list is an ODF feature, defined by reading together the description of 'list' element [1], and its 'continue-numbering' [2], 'continue-list' [3], and 'style-name' [4] attributes. In essence, continue-list allows to continue an arbitrary list by its id, regardless of its style; and 'style-name' allows to assign any style, irrespective of other chained lists styles. It could be not always useful, would most times be undesirable, but it is used in real applications, so must be supported :) [1] https://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part3-schema.html#element-text_list [2] https://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part3-schema.html#attribute-text_continue-numbering [3] https://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part3-schema.html#attribute-text_continue-list [4] https://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part3-schema.html#a_19_880_22__text_list_
(In reply to Mike Kaganski from comment #5) > (In reply to ajlittoz from comment #4) > [1] > https://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part3- > schema.html#element-text_list > [2] > https://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part3- > schema.html#attribute-text_continue-numbering > [3] > https://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part3- > schema.html#attribute-text_continue-list > [4] > https://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part3- > schema.html#a_19_880_22__text_list_ Thanks for the pointers. IMHO, [2] continue_numbering is ambiguous. It is not clear at all what the "preceding list" is. In my mental model (but I might be wrong), a list is identified by its list style. Consequently, I read "preceding list" as being a preceding list with the same list style, not the immediate preceding list whatever its list style. My reading results in very consistent documents where I can intermix two independent lists (at same level) because they relate to two data flows. The second understanding makes sense for compatibility with Word and common non-structured approach to lists, i.e. using toolbar buttons instead of styles. I understand the argument about not breaking existing documents but it certainly complicates implementation by imposing guesses about author's intention and probably tweaking the neat initial design into some more or less tricky trade-off. [3] continue_list clearly designates the list to be continued. I think this is safer (assuming I understand how it works) than continue_numbering because the "preceding" list is explicitly named. This allows to chain lists under different styles. However I don't see how to activate it in the GUI. Since I suspected usage of flags like "restart numbering" or "continue numbering" in your sample file, I used the style inspector (though it is not as useful as it could in presence of list styles because it reports them as direct formatting) and Format>Lists>… to get the current state but I saw none of these flags. There is perhaps some weakness here in state reporting. === Reading the referenced clauses to ODF, I found a definition of "list header". Are they simply "unnumbered entries" apart from the fact they precede (numbered) list items? Since header and unnumbered entries have not the same semantic value, is there any way to tag an entry as header in the GUI? This also means that, when reordering list entries, headers are protected in some way so that they always remain at top of list.
(In reply to ajlittoz from comment #6) > IMHO, [2] continue_numbering is ambiguous. It is not clear at all what the > "preceding list" is. In my mental model (but I might be wrong), a list is > identified by its list style. Consequently, I read "preceding list" as being > a preceding list with the same list style, not the immediate preceding list > whatever its list style. No, it is not ambiguous. In the context of the OASIS standard, "list" is defined by 'list' element with level of 1 (see [1]); so "previous list" is simply defined by the previous corresponding element. But as *explicitly* specified in [2], it only considers the immediately preceding list, *if* it has the same style - so it can't continue numbering of lists with different styles, only with same-style ones. But I likely should have omitted [2] from my references, because it doesn't directly relates to your question, which is exactly about that different-styles-in-single-list curiosity, and it's [3] that allows that. > I understand the argument about not breaking existing documents but it > certainly complicates implementation by imposing guesses about author's > intention and probably tweaking the neat initial design into some more or > less tricky trade-off. I hope that I clarified the confusion that I created by inclusion of [2]; basically, [2] completely aligns with your mental model. > [3] continue_list clearly designates the list to be continued. I think this > is safer (assuming I understand how it works) than continue_numbering > because the "preceding" list is explicitly named. This allows to chain lists > under different styles. However I don't see how to activate it in the GUI. I also don't see it in GUI; but it can easily happen during DOC(X) conversion, to our mutual happiness ;P > Since I suspected usage of flags like "restart numbering" or "continue > numbering" in your sample file, I used the style inspector (though it is not > as useful as it could in presence of list styles because it reports them as > direct formatting) and Format>Lists>… to get the current state but I saw > none of these flags. There is perhaps some weakness here in state reporting. Style inspector is unfortunately not evolving; it misses much - like proper support of list styles / DF, in addition to character and paragraph ones. > Reading the referenced clauses to ODF, I found a definition of "list > header". Are they simply "unnumbered entries" apart from the fact they > precede (numbered) list items? Since header and unnumbered entries have not > the same semantic value, is there any way to tag an entry as header in the > GUI? This also means that, when reordering list entries, headers are > protected in some way so that they always remain at top of list. It could be implemented this way in the document model, and then could have the properties that you expect. But they are not. Additionally, there is tdf#155834, which shows how we do not handle list items as a whole properly in the UI; the "unnumbered entries" should not be handled paragraph-by-paragraph, but together as a single item; that would affect the "heading" entries as well, if they were different in the document model.