Bug 35217 - Allow a child outline level to express the numerical value of its parent level with a different numbering style than the parent
Summary: Allow a child outline level to express the numerical value of its parent leve...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.3 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Heading-Numbering
  Show dependency treegraph
 
Reported: 2011-03-11 08:15 UTC by Joseph Alexander Sochet, Esquire
Modified: 2024-07-13 12:20 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
new "All sublevels Arabic" option in "Bullets and Numbering" (52.20 KB, image/png)
2024-07-13 12:05 UTC, Damian Hofmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Alexander Sochet, Esquire 2011-03-11 08:15:39 UTC
Unlike many other word processing tools such as MS Word, the outlining tool in LO does not allow complex outline number formatting.  This bug may actually be 2 or 3 bugs in one, and I will split it up if necessary.  Here is the example which explains the bug.  Many legal documents use roman numeral formatting for document sections and call them thins like Articles 
and then use Arabic numerals that include reference to the parent section number, and use leading zeros for list numbering of the subsections. For example,  ARTICLE I would be a section where the outline format would be ARTICLE n where n is a sequential Roman numeral.  A subsection to ARTICLE I would be 1.01.  Where the format would be n.mm where n is the Arabic equivalent of the sequential Roman numeral and the mm is a leading zero, that is two digit, sequential Arabic number.  
LO offers no functionality to use a different numerically equivalent format for the child outline number, or the two digit functionality for the child. This is not just fairly common style for legal documents, it is sometimes required by local formatting standards.
Comment 1 Alex Thurgood 2011-03-11 08:55:05 UTC
Hi,

I can confirm this, having tried to reproduce what you wanted to do after I saw the posting on the users list. I haven't played with the styles to see whether the objective can be attained through the clever use of styles though, but it does seem that the automatic numbering function used for list numbering prevents the user from defining the numbering in the way you indicate. I can also confirm that this kind of numbering is very common in legal instruments.


More of a feature request than a bug though.

Alex
Comment 2 Steve Edmonds 2011-05-31 17:32:34 UTC
I can't create what is required in styles. A special tag (i.e. {L} for level, or {PL} for previous level) could enable this feature if placed in the "Before" field or if there was a tick box to force numbering on position (i.e. so iV and D both number as 4). 
I think more of a feature request than a bug.
Comment 3 Björn Michaelsen 2011-12-23 11:45:19 UTC Comment hidden (obsolete)
Comment 4 Joseph Alexander Sochet, Esquire 2011-12-30 09:07:01 UTC
Tested again in LO 3.5.5 Beta2.  With the same results.  Essentially this is a feature request for more advanced list numbering that is very useful for attorneys or those that must format section/paragraph/outline numbering in certain ways because of legal requirements or because of standard style.  Sorry for testing so late.  I can provide more examples.
Comment 5 Joseph Alexander Sochet, Esquire 2011-12-30 09:10:54 UTC
(In reply to comment #4)
> Tested again in LO 3.5.5 Beta2.  With the same results.  Essentially this is a
> feature request for more advanced list numbering that is very useful for
> attorneys or those that must format section/paragraph/outline numbering in
> certain ways because of legal requirements or because of standard style.  Sorry
> for testing so late.  I can provide more examples.

Whoops 3.5.0 Beta2 I tested it in the future.
Comment 6 Joseph Alexander Sochet, Esquire 2012-05-08 14:19:13 UTC
Problem (lack of feature) still exists in version 3.5.3.2 (Release). I am pretty sure I should have changed this to new after I tested back in December, so Doing that as well
Comment 7 Timur 2013-05-17 18:30:38 UTC
While I find this rather important, I edited https://wiki.documentfoundation.org/Feature_Comparison:_LibreOffice_-_Microsoft_Office#General_office_suite:_LibreOffice_vs._Microsoft_Office and added Complex Outline numbering / Multilevel list.
I marked LO support as partial.
Comment 8 J. Kanowitz 2013-10-26 00:37:21 UTC
To document a simpler but related case in legal documents, consider the following as may be used in a US District Court pleading where all paragraphs must be consecutively numbered:

  1.  Introductory paragraph.
  2.  Introductory paragraph.
A. FIRST SECTION HEADING
  3.  Paragraph in first section.
  4.  Paragraph in first section.
         Specially formatted, un-numbered blockquote citation.
         Specially formatted, un-numbered blockquote citation.
  5.  Paragraph in first section.
B. NEXT SECTION HEADING
  6.  Paragraph in next section.

Conceptually, headings belong at a 'higher' level than the body text paragraphs, but I couldn't trick Tools->Outline Numbering in 4.1.2.3 to:
- Allow "A." to occur in the 1st level when 2nd level paragraphs already existed;
- Give consecutive numbering in the 2nd level only;
- Avoid prepending the numbering divider "." to paragraphs of 1st or 2nd outline style when numbering is turned off (as one might do to quickly direct-format blockquotes without defining a new style).

This can be worked around by using a "Paragraphs" list and a "Headings" list, but that loses rapid raise/demote and incurs some annoyance-grade chicken and egg problems (make a heading a member of the Headings list - then apply Heading 1 format - now go back and make it a member of the list again because numbering got turned off).

Use of capital letters for headings in the example is arbitrary, could be Roman or anything else.
Comment 9 sophie 2013-11-06 09:27:44 UTC
Still present in Version: 4.1.3.2
Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a - Sophie
Comment 10 Björn Michaelsen 2014-01-17 09:51:49 UTC Comment hidden (obsolete)
Comment 11 tommy27 2014-05-10 11:40:19 UTC
please give an update about the bug status with current 4.2.4.2 LibO release.

if bug is still here, please move it from mab4.1 list to mab4.2 since 4.1.x reached END OF LIFE
Comment 12 Joel Madero 2014-05-23 01:36:32 UTC
From reading this - I'm convinced that it's an enhancement request. It's a missing feature in LibreOffice - not something that exists but is broken (by definition an enhancement request) 

Marking as such and removing from MAB list - it does not belong there.
Comment 13 Owen Genat (retired) 2014-09-24 05:15:59 UTC
This entire bug needs clarification. Legal document the world over are reknown for using highly specific styling that often break every other convention used. The examples in comment 0 and comment 8 are explicitly NOT outline numbering, which as the name suggests indicates exact position in a document. By all means implement a new numbering scheme but label it "legal" or something similar, rather than outline.
Comment 14 Steve Glines 2016-05-25 07:02:32 UTC Comment hidden (obsolete)
Comment 15 Timur 2017-02-01 13:24:23 UTC Comment hidden (obsolete)
Comment 16 Alex Jordan 2019-07-02 07:12:33 UTC Comment hidden (spam)
Comment 17 Jason White 2019-08-13 14:10:59 UTC
Can confirm that this feature is still missing and is prohibiting the adoption of LibreOffice in my line of work (Engineering). We need to have numbered headings and subparagraphs (with different paragraph styles possible for each level of numbering and indentation) for requirements.
Comment 18 Xisco Faulí 2019-11-29 13:29:29 UTC
Changing priority back to 'medium' since the number of duplicates is lower than 5
Comment 19 sdc.blanco 2020-01-03 23:14:16 UTC
Comment 13 points out that this bug report is not focused.

Have rewritten the summary to make a focus on the first of two problems that were identified in the original report.

The technical problem behind the summary:  Consider a document with two outline levels, expressed respectively in paragraph styles: Heading 1 and Heading 2.

Heading 1 is numbered with Roman numerals.

I.  Heading 1

The next outline level (the child) is currently "forced" to use the numbering style of the parent level.  Say that Heading 2 is numbered with Arabic numbers.  At present, it would appear as:

I.1  Heading 2

The enhancement request is to allow the child (in this case the style Heading 2) to take the parent's numerical value (where in this example, the value is "1"), and allow Heading 2 to decide the style of expression for this numerical value. For example.

1.1  Heading 2    or  A.1 Heading 2

I could not find other bug reports that expressed this particular problem, which is expressed clearly here (and which others have noted as a problem).  

The second problem raised in the original report (about "leading zeros") is similar to bug 62654, which is noted in See Also.
Comment 20 virat singh 2021-03-03 11:45:15 UTC Comment hidden (spam)
Comment 21 ipowala 2021-04-10 11:37:41 UTC Comment hidden (spam)
Comment 22 ipodata.in 2022-01-05 02:42:45 UTC Comment hidden (spam)
Comment 23 world777 2022-06-06 03:15:09 UTC Comment hidden (spam)
Comment 27 Damian Hofmann 2024-07-13 12:05:02 UTC
Created attachment 195277 [details]
new "All sublevels Arabic" option in "Bullets and Numbering"

#150408 is possibly related to this. A new option "All sublevels Arabic" was added to the "Bullets and Numbering" dialog. Seems that this would allow at least some of the use cases described here.

In my own (quick) testing, this is still not available for heading styles, only for lists. And some use cases still don't work.

E.g.:

A
A.IV
1.4.1

works fine.
But I see no way to do something like:

A
1.IV
1.4.a

Admittedly, this last example is probably ridiculous. It's just meant as a showcase, what a truly flexible numbering system could do. If it can do that, it should be able to cover almost any thinkable use case.