Created attachment 180846 [details] Behaviour of "suppress final separator" feature with custom after separator Follow on to AskLO question https://documentation.libreoffice.org/en/english-documentation/ When using the "Number" option of cross-reference to a numbered paragraph (heading or list item), Writer suppresses one U+002E FULL STOP if it appears as the last character in After separator of the list style definition. This is satisfactory in the vast majority of cases where numbering is of the form "1." and the cross-reference will be "See step 2 in the previous procedure" to point to item "2. Second step". It does not work if author chooses another After separator the a full stop. But authors expect the final separator to be suppressed, be it multi-character or different from full stop. In other words, when the reference is inserted, the list style definition (this includes Format>Bullets & Numbering in case a real list style is not used but this may be more complicated due to its "polymorphism") should be queried to retrieve the effective After separator for this level. See present behaviour in attached sample file
See also bug 146851
Update to > But authors expect the final separator to be suppressed, be it multi-character or different from full stop. Thinking about it, suppression is more complicated. List number may be decorated with both Before and After separators. Both should be suppressed. This requires querying the level in the list style definition or retrieving the multi-level counter without adding the "side" separators. == Example for single-level list: [1] Step one [2] Step two In step 2 above, … == end of example == Example for multi-level list: [1] Step one <1.1> First sub-step in first step In action 1.1 above, … == end of example *** The following remark is not part of the present feature request. *** List style allows to define many decorators (before and after separators at each level) but the "internal" separator is hard-coded at full stop. It can't be replaced by a dash for example. Is there a "typographical" reason for it? It don't see an exclusive agreement in books. Other conventions exist.
Confirming one dot is suppressed (.. list after = . at references and ... = ..) but not when using different characters (-- = -- and --- = ---). Sounds like a bug. But I wonder if this is supposed to be a convenience feature for cases like "1. One... As written in chapter 1 this is not...". According to the online help, the context is just showing the superior level or not, while I thought this option controls whether the before/after text is added. Mike, please add some wisdom here.
(In reply to ajlittoz from comment #0) > Follow on to AskLO question > https://documentation.libreoffice.org/en/english-documentation/ The link is likely wrong ;) (In reply to Heiko Tietze from comment #3) > According to the online help Heiko: it is good to develop a muscle memory to add a link as soon as your fingers type something like "according to" ;) In principle, I agree that if it strips a single dot, it must strip the whole thing. But likely it should be configurable with regards of stripping "before", "after", or both: the "before" might in principle be wanted, like "Chapter" or "Appendix", while "after" may need removal. But that's a separate request. So for the sake of this specific thing: if it strips a trailing dot, it must not be selective for a single dot, and accept both multiple dots, and non-dots. Interesting to find the code - maybe its comments (or commit details) could shed some light on context - like "suppressing other stuff may break existing documents, or be unwanted in such and such scenario"...
I confirm, that there is the following inconsistency: Bullets and Numbering: If last part of the separator is a dot, dot is displayed in "Number (no / full context)" Chapter Numbering: If last part of the separator is a dot, dot isn't displayed in "Number (no / full context)" Tested with following separators . .. .? ?. For me, result should be the same for cross references to numbered paragraphs and to chapters.
Link to AskLO question: https://ask.libreoffice.org/t/writer-and-cross-references-to-numbered-lists-how-can-i-remove-the-full-stop/78759/ (Sorry for msihap; I had several tabs open in my browser and didn't fully check which link I pasted. It's a shame we can't edit comments here.) (In reply to Mike Kaganski from comment #4) >But likely it should be configurable with regards of stripping "before", >"after", or both: the "before" might in principle be wanted, like "Chapter" or >"Appendix", while "after" may need removal. But that's a separate request. This is a valuable suggestion. Depending on whether you consider this report is a bug (due to the inconsistencies in behaviour) or a feature request (implying a reimplementation of the feature), this could be included by providing a clear specification. If you go into this direction, include also a customisation for the "inner" separator(s) which is presently hard-coded at dot. I think for consistency reason that a single "inner" separator should be specified, i.e. 1.1.1.1 as of today or 1-1-1-1 as found is some books but not 1.1-1+1 as this is ugly and difficult to read (I don't think I have ever seen such a numbering) not speaking of the nightmare to implement.
Might also be useful to add informations about separators in documentation of cross reference dialog: https://help.libreoffice.org/7.4/en-GB/text/swriter/01/04090002.html?System=WIN&DbPAR=WRITER&HID=modules/swriter/ui/fldrefpage/FieldRefPage#bm_id3149042 Shall I open a new report for that?
(In reply to Dieter from comment #7) > Might also be useful to add informations about separators in documentation > of cross reference dialog: > https://help.libreoffice.org/7.4/en-GB/text/swriter/01/04090002. > html?System=WIN&DbPAR=WRITER&HID=modules/swriter/ui/fldrefpage/ > FieldRefPage#bm_id3149042 > Shall I open a new report for that? The help for "Number" reference format is not immediately understandable but after a couple trials it becomes obvious. However, there is a problem with the field. If you explicitly select a specific format, no context/full context, this choice is not reported back when you edit the field later. You always get "Number (no context)", even if you selected the auto mode. Should this be reported as a separate bug? Or, in your opinion, is there some reason why it is displayed so on edit? ==One comment== When referencing headings, you can do it two ways (doesn't apply to other numbered paragraphs because they are not headings): - as "Chapter", in which case I expect all separators to be present, unaltered because I really mean a reference to a chapter and I'll use to inline something like a TOC entry - as "Number" where I semantically drop the heading meaning and keep only the list "value"; in this case I want only the numbering without Before and After separators Of course, this implies a difference in processing according to the type of the field, not on the attributes of the referenced paragraph (this may be what is done in the code and would explain the difference in dot suppression. As already mentioned, for a given field "type", result should not depend on paragraph style (member of the outline hierarchy or not). The difference must result exclusively from a deliberate choice by user: "Chapter" or "Number". If this is enforced in code, then some brief mention could be made in the help, such as "Keeps all separators" for "Chapter" and "Suppresses all separators" for "Number".
(In reply to ajlittoz from comment #6) > include also a customisation for the "inner" separator(s).. You can define before/after per level and something like 1:, 1-, 1. is taken into the reference. But when using sublevels it's always 1.1.1, in other words the internal number separator is a dot. MSO allows to enter the number format by showing the actual value with highlighting. Something like "1.1-" for the second level (the colon is ignored) and allows to change the dot here into a dash, for example. However, while this is shown on the heading it is not at the cross-reference.
(In reply to Heiko Tietze from comment #9) > MSO allows to enter the number format by showing the actual value with > highlighting. Something like "1.1-" for the second level (the colon is > ignored) and allows to change the dot here into a dash, for example. > However, while this is shown on the heading it is not at the cross-reference. IMHO, if the cross-reference does not echo exactly (except for Before and After separators) what appears in text, it is a source of confusion for users. As already mentioned many times, if MSO did things wrong, we are not committed to perpetuate the error. The most important thing for LO (Writer here) is to have a consistent, predictable and clearly described behaviour. Regarding the inner separator, I don't mind there is a single one (because I have not met contorted examples of a mixture of separators) but it would be really nice to be able to customize it through configuration and not through a direct-formatting-like tweak as in MSO. Cheers.
UX wise I could imagine two solutions: first, we could add an option at the cross-reference dialog whether a checkbox "[ ] Remove last separator" or another item "Number (w/o trailing separator)" (probably not so good since it comes on top of with/without context). But since a trailing separator is likely either always used in case of a dot (1.1.) or never, for example a colon (1.1:), the better approach might be to add the option "[x] Apply at cross-references" to the list configuration. Such an option needs to be available cross-application to keep it on round-trips.
Note: before https://gerrit.libreoffice.org/c/core/+/117156 (landed in 7.2), it already removed everything *after*. In tdf#144563, the dot removal was *selectively* restored.
*** Bug 153680 has been marked as a duplicate of this bug. ***
(In reply to ajlittoz from comment #0) > But authors expect the final separator to be suppressed, be it > multi-character or different from full stop. Not all authors, and not always. Some people want suppression sometimes, and some people want no-suppression sometimes. Also, the same is true for the first "before" separator, before the outermost level of numbering. So I actually suggest marking this one as a dupe of my bug 147774.