Description: In a document with an ordered numeric list with all sub-levels (e.g., three levels 1, 1.1, and 1.1.1), if you want to indent or align each level’s heading from the left margin by some predetermined amount that increases with each sub-level to help differentiate the different levels (e.g., Heading 1 or level 1 set to 0.00", Heading 2 or level 1.1 set a 0.25", and Heading 3 or level 1.1.1 set at 0.50"), the first and second levels are applied and work fine when OK is pressed, but the third level fails to move the amount specified via… Format > Bullets and Numbering > Position In other words, if you change the Aligned at: setting for Level 1 to 0.00″, Level 2 to 0.25″, and Level 3 to 0.50″ and press OK, the change will only apply to the first two levels and not the third. Also note that when you scroll the Aligned at: up for a larger indent in Level 3 that the change in the Preview pane is actually moving the Level 2 alignment—not the Level 3 alignment. One more thing to note, and that is that in the Preview pane all three levels display correctly if you select Level 1 or Level 2, but if you select Level 3 the Preview pane will not only NOT align the Level 3 headings as desired—but it will indicate the first numeral to be a 0 instead of a 1. However, if you go to the Customize tab, all three levels displayed in the Preview pane do display the correct numerals and alignments. Additionally, these symptoms for Level 3 only appear in the Preview pane and do NOT affect or overwrite those already set up for Level 2 (in other words, Level 2 displays as intended in the document, but Level 3 fails to align at all). The same is true if you use the Sidebar to access Styles > List Styles and then R-click on Numbering 123, then click on Modify…, and then go to the Position tab. The Preview pane shows the correct alignments until you click on Level 3. Steps to Reproduce: 1. Set up an ordered numeric list with all sub-levels (see example provided) 2. Set Heading indents or alignment as suggested above for Levels 1-3 (or more) Actual Results: From the third sub-level down, the alignment fails to apply itself to the alignment settings you set--plus, the alignment--as it appears the Preview pane, is in Level 2 instead of Level 3 and has a leading 0 instead of a leading 1 (this does not transfer to the actual document--only as it appears in the Preview pane. Expected Results: Level 3 on down should align as selected and the Preview pane should indicate those changes in the correct level and not indicate a leading 0 when the start from is set to 1. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.2.0.2 (x64) / LibreOffice Community Build ID: 614be4f5c67816389257027dc5e56c801a547089 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Created attachment 174329 [details] Sample Document
Created attachment 174330 [details] Screenshot of Level 2 (correct)
Created attachment 174331 [details] Screenshot Level 3 (Incorrect)
I confirm it with Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 74d35e143d557a7e65c4443f5b80cb9d406b1fa1 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL but you tested with wrong dialog Steps to reproduce 1. Open attachment 174329 [details] 2. Tools => Chapter numbering => Level 3 => Position 3. Indent setting is 1,27 cm (in document 0 cm) 4. change indent to 2 cm => Nothing happens Also testd in Safe Mode and 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
There is no real problem here (see below), but I only see this happening for level 3 and not level 4 or below. I saw the same thing happening for level 4 etc until LO 5.2 which was fixed by author Luke Deller on 2016-05-10 07:23:33 +0000 commit 77171fc384b3c6359cdae026a0c38f2f112c9d60 Remove default outline indent, fixes tdf#95576 Earlier in 5.2 (and 5.1) we couldn't change the value at all - the UI was broken. Fixed by author Noel Grandin on 2016-04-05 09:41:31 +0200 commit c10d56c6c33ad27d9f4fb12e499a8b246d88da9f tdf#98647 fix bug in tools->outline-numbering Level 3 was already acting differently (while level 4 worked) in LO 3.5. BUT - ALL OF THAT IS IRRELEVANT because in this doc, heading 3 has been defined with some specific properties that are not specified in the other headings. <style:style style:display-name="Heading 3"> <style:paragraph-properties fo:margin-left="0in" fo:margin-right="0in"/> So the style has hard-coded a zero left margin - which overrides the numbering values. When these two margins are removed from styles.xml, then the chapter numbering values can take effect. (This can be see in the UI by editing the style and looking at the Organizer tab. To fix, on the Indents & Spacing tab, press "Reset to parent".)
Justin, thank you for further investigations. You're right. There seems to be a problem with style "Heading 3". But I have two questions here: 1. I can't see a difference in organizer tab between "Heading 2" (that works as expected) and "Heading 3". So could you please specify? 2. I would expect that this setting would be overwritten by numbering values So perhaps we don't have the described bug, but a bug, that is underlying? => I changed bug description a bit and set status back to UNCONFIRMED.
(In reply to Dieter from comment #6) > 1. I can't see a difference in organizer tab between "Heading 2" (that works > as expected) and "Heading 3". So could you please specify? Heh. I never actually checked the others in Organizer. Indeed, they do say 'Indent left 0'. I don't know why they would though. Using the new Style Inspector does make it clearer - where only heading 3 has "Para Left margin" set. > 2. I would expect that this setting would be overwritten by numbering values No. That's not correct. When we apply a list via a list style or via the toolbar, we are applying it directly to the paragraph. Direct formatting has priority over styles. When the numbering is applied via a style, the numbering no longer has priority. You can test this by assigning a list-style to a paragraph-style (like Addressee) and setting a -0.2 left margin to the paragraph style. The -0.2 margin will win out. So this is acting consistently and I would say properly.
(In reply to Justin L from comment #7) > (In reply to Dieter from comment #6) > > 1. I can't see a difference in organizer tab between "Heading 2" (that works > > as expected) and "Heading 3". So could you please specify? > Heh. I never actually checked the others in Organizer. Indeed, they do say > 'Indent left 0'. I don't know why they would though. Using the new Style > Inspector does make it clearer - where only heading 3 has "Para Left margin" > set. Very strange. I've done some further tests: 1. "Reset to parent" doesn't work. 2. If you create a new style that is inherited from "Heading 3" alignment works. 3. Heading 3 works well with a new document. Eak! A Bug, Kill it!, do you have any informations about the way paragraph style "Heading 3" has been changed and give some steps to reproduce? If not, we should close this bug as RESOLVED INSUFFICIENTDATA => NEEDINFO
(In reply to Dieter from comment #8) > 1. "Reset to parent" doesn't work. Make sure you are on the Indents tab when you do it. I think that button only works tab-by-tab, not to the style as a whole. > do you have any informations about the way paragraph > style "Heading 3" has been changed and give some steps to reproduce? Just change Left margin to something (1 inch) and then change it back to 0.
(In reply to Justin L from comment #9) > Make sure you are on the Indents tab when you do it. I think that button > only works tab-by-tab, not to the style as a whole. Yes correct (perhaps it should be greyed out in organiser tab, but that's a different topic) > Just change Left margin to something (1 inch) and then change it back to 0. Yes, it works, but in comparison between heading 2 and heading 3 we have an inconsistency between organiser tab and style inspector. But I think that should not be discussed in this bug. Justin, thanks for advice. Let's close it.
(In reply to Dieter from comment #4) > I confirm it with > > Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community > Build ID: 74d35e143d557a7e65c4443f5b80cb9d406b1fa1 > CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: > win > Locale: de-DE (de_DE); UI: en-GB > Calc: CL > > but you tested with wrong dialog > > Steps to reproduce > 1. Open attachment 174329 [details] > 2. Tools => Chapter numbering => Level 3 => Position > 3. Indent setting is 1,27 cm (in document 0 cm) > 4. change indent to 2 cm => Nothing happens > > Also testd in Safe Mode > > and 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 Yes, the same behavior is exhibited in the Chapter numbering method as well. In either case, Level 3 is messed up and defaults to the left margin setting as if direct styling was used by the user instead of using styles.
(In reply to Justin L from comment #5) > There is no real problem here (see below), but I only see this happening for > level 3 and not level 4 or below. > > I saw the same thing happening for level 4 etc until LO 5.2 which was fixed > by author Luke Deller on 2016-05-10 07:23:33 +0000 > commit 77171fc384b3c6359cdae026a0c38f2f112c9d60 > Remove default outline indent, fixes tdf#95576 > > Earlier in 5.2 (and 5.1) we couldn't change the value at all - the UI was > broken. Fixed by author Noel Grandin on 2016-04-05 09:41:31 +0200 > commit c10d56c6c33ad27d9f4fb12e499a8b246d88da9f > tdf#98647 fix bug in tools->outline-numbering > > Level 3 was already acting differently (while level 4 worked) in LO 3.5. > > > BUT - ALL OF THAT IS IRRELEVANT because in this doc, heading 3 has been > defined with some specific properties that are not specified in the other > headings. > > <style:style style:display-name="Heading 3"> > <style:paragraph-properties fo:margin-left="0in" fo:margin-right="0in"/> > > So the style has hard-coded a zero left margin - which overrides the > numbering values. When these two margins are removed from styles.xml, then > the chapter numbering values can take effect. (This can be see in the UI by > editing the style and looking at the Organizer tab. To fix, on the Indents & > Spacing tab, press "Reset to parent".) I do not understand how you can state that there is no problem because it only happens on one level - especially when you go on to point out that this same thing happened in the past, but on a different level. You found exactly what I found, but I did not use direct styling on that sample document. The same thing happens on any document I create from scratch - not from a template. The process you outlined may work (I have yet to try it), but it is too involved for the average user to implement, and it should not be necessary in any case. Plus, how is the average user even to know where to look for a solution? An awful lot of potential users leave LO out of sheer frustration over how difficult it is to learn and these little bugs just add to their frustration. Well, that is just my opinion, but I believe a valid one.
(In reply to Eek! A Bug. Kill it! from comment #12) > I do not understand how you can state that there is no problem because it > only happens on one level - especially when you go on to point out that this > same thing happened in the past, but on a different level. Make sure you read the earlier responses carefully. I never said it wasn't a problem because it only happens on one level. Yes, in the past the style set a specific zero margin on ALL heading styles, but that was fixed in 5.2 (including for level 3). That bug/fix is completely disconnected from the reason why level 3 is causing you trouble though. I explained why earlier, and you can unzip your document and look at styles.xml and see that only Heading 3 has a left margin specified (as zero). Based on the instructions in the style definition, LO is doing exactly what it is told to do, and that is why there is no problem. > The same thing happens on any document I create from scratch Please do make this new example from scratch and submit it. I would actually be surprised if you can do it. Make sure you document all the steps so that others can reproduce it too. > The process you outlined may work, but it is too involved for the > average user to implement, and it should not be necessary in any case. The average user will never run into this situation. This only happens when a style is changed to give it a non-default value. (And this is a perfectly legitimate operation that some users might want to do intentionally. Everything here is consistently following the rules of inheritance priority.) My process is not actually complicated. -the user somehow specifies a setting in a style, but now wants to clear that direct setting and inherit it from the parent style instead. -the user presses the Reset to Parent button on the relevant tab (previous just labelled as "Standard" I expect). Powerful software by definition allows complicated situations.
(In reply to Justin L from comment #13) > (In reply to Eek! A Bug. Kill it! from comment #12) > > I do not understand how you can state that there is no problem because it > > only happens on one level - especially when you go on to point out that this > > same thing happened in the past, but on a different level. > Make sure you read the earlier responses carefully. I never said it wasn't a > problem because it only happens on one level. > > Yes, in the past the style set a specific zero margin on ALL heading styles, > but that was fixed in 5.2 (including for level 3). > > That bug/fix is completely disconnected from the reason why level 3 is > causing you trouble though. I explained why earlier, and you can unzip your > document and look at styles.xml and see that only Heading 3 has a left > margin specified (as zero). Based on the instructions in the style > definition, LO is doing exactly what it is told to do, and that is why there > is no problem. > > > The same thing happens on any document I create from scratch > Please do make this new example from scratch and submit it. I would actually > be surprised if you can do it. Make sure you document all the steps so that > others can reproduce it too. > > > The process you outlined may work, but it is too involved for the > > average user to implement, and it should not be necessary in any case. > The average user will never run into this situation. This only happens when > a style is changed to give it a non-default value. (And this is a perfectly > legitimate operation that some users might want to do intentionally. > Everything here is consistently following the rules of inheritance priority.) > > My process is not actually complicated. > -the user somehow specifies a setting in a style, but now wants to clear > that direct setting and inherit it from the parent style instead. > -the user presses the Reset to Parent button on the relevant tab (previous > just labelled as "Standard" I expect). > > Powerful software by definition allows complicated situations. Justin, it seems that I owe you a sincere apology. I was struggling to learn the whole styles method of creating documents and must have somehow changed that level 3 left outline list margin setting inadvertently because I have no recollection of having done so (it was after all a fairly short test document that I created specifically to follow along with a LO Writer Styles video tutorial). I was aware from my reading of the manual that direct formatting takes precedence, which makes sense, but I did not think I had changed any settings directly. I made use of the Style Inspector and noticed what you did, but I could not find a way to manually change the errant margin setting, and since everything in the Bullets & Numbering dialog looked correct (except as noted), I presumed there was indeed a bug. You were also correct in that the problem did NOT exhibit itself in a new document, which I am absolutely certain I tried before writing this bug report to verify my bug assumption, but alas a new document today works fine. Not sure why, but obviously it’s either something I did (if you make a mistake once, you are apt to make the same mistake again moments later due to muscle memory) or it’s this touchy Asus keyboard once again having a mind of it’s own.