1. New Document. 2. Insert one or two words, and apply H2 paragraph style. 3. On another line after the H2 paragraph, Insert Field (Ctrl+F2), Document tab - Chapter - Chapter Name / Level = 1 4. Insert / Close Actual result: text with H2 paragraph style is displayed Expected result: Nothing is shown. 5. Edit Field 6. Change Level to a large number (e.g., 6) 7. Ok Actual result: text with H2 paragraph style is still displayed Expected result: Nothing is shown. Pressing F9 (or Tools > Update > Update All) (several different times) has no effect. According to extended tooltip for Level: "Select the chapter heading level that you want to include in the selected field." According to entry for "Level" in [1]: Enter outline level of the chapter to be displayed. The inserted field will display the value taken from last paragraph with the specified outline level placed before the inserted field. [1] https://help.libreoffice.org/7.4/en-US/text/swriter/01/04090001.html
I confirm it with Version: 7.2.5.2 (x64) / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: default; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded
@Dieter -- I think this report might be a DUP of bug 92805 or bug 93904
(In reply to sdc.blanco from comment #2) > @Dieter -- I think this report might be a DUP of bug 92805 or bug 93904 I think bug 92805 is different (related to headers); bug 93904 might be a duplicate, but your description is more concrete.
Having a deeper look into bug 92805 I would say it's the same, but as I said description here is easier to understand.
Created attachment 177831 [details] demonstration of level behavior Attached file gives better demonstration of "actual" behavior. The “rule” that fits the observations is: If the "Level" set for a "chapter name" field is greater than or equal to ( ≥ ) outline level of the first immediately preceding paragraph with an outline level, then show that paragraph in the field.
Modified summary -- and just to clarify the "rule" in comment 5 - to avoid confusion -- because the numerically smaller (less) outline 1 being is hierarchically higher (more) than outline level 2. The chapter field shows any immediately preceding paragraph that has an outline level that is numerically less than or equal to the level setting for that field. According to the documentation. It should only show the last preceding paragraph that has the same outline level (according to the documentation).
(In reply to Dieter from comment #3) > bug 93904 might be a duplicate Bug 93904 also seems to note the issue of which "level" heading is picked up by the chapter field, but its main focus is about how the chapter field is displayed in the "header". See attachment 118401 [details], where the level 2 heading on page 1 is not "picked" up by the field with level 2 setting in the header on page 1. Also, as noted (indirectly) in the OP for 93904, the header for page 2 uses the H1 and H2 from page 1, even though a new H1 and H2 appear on page 2 (hence the comment in the OP about "END" of the page). Those issues are different from the issue described here -- which does not involve the headers. It is not clear that fixing the issue here would also solve the issue of the headers.
(In reply to sdc.blanco from comment #5) > The “rule” that fits the observations is: > If the "Level" set for a "chapter name" field is greater than or equal to ( > ≥ ) outline level of the first immediately preceding paragraph with an > outline level, then show that paragraph in the field. But that's not the desired behaviour, I think. For me desired behaviour is "Show paragraph in the field, if the "Level" set for a "chapter name" field is equal to outline level of the first immediately preceding paragraph" (and therefore I don't understand bug summary)
(In reply to Dieter from comment #8) > But that's not the desired behaviour, I think. For me desired behaviour is > "Show paragraph in the field, if the "Level" set for a "chapter name" field > is equal to outline level of the first immediately preceding paragraph" Agreed. That is also what the documentation says. I am not proposing any changes to this desired behavior. > therefore I don't understand bug summary) Did you see the "not" ? The summary is written in relation to the current behavior, and says that paragraphs with outline levels below the level setting of field should not be shown -- which should then result in the desired behavior.
@Dieter - I think this ticket is NAB (or a "documentation" problem, which should be fixed now with bug 153560). The actual behavior of "level" is to use the immediately prior heading, where the "level" option is to control how many levels of the heading number are displayed. (The UI control is now relabeled "Up to level", and the tooltip/extended tip and help page are updated.) Not sure how to "resolve" this ticket. I do not know if you want to file a new ticket in relation to your comment 8.
Created attachment 185589 [details] Test file to demonstrate the effect of the "level" control Marking previous comment as no-value, because of (possible) new discovery,and this comment replaces comment 5 (which is now marked as obsolete). Attached file gives demonstration of "actual" behavior of "level" spinbox, when type "Chapter" field uses format "chapter name" or "chapter number and name". The rule is: Show contents of the first immediately preceding paragraph that has an outline level less than or equal to (≤) the number entered in the "outline level" spinbox. Meanwhile, a different rule is operative when the formats are "chapter number" and "chapter number without separator". In that case, the rule is: use the immediately prior heading, where the "level" option controls how many levels of the heading number are displayed. (bug 153560 updates the help and tips in relation to these formats). Trying to clarify the discrepancy between how the "level" control operates with the different formats (starting in bug 153560 comment 9).
(In reply to sdc.blanco from comment #11) > Meanwhile, a different rule is operative when the formats are "chapter > number" and "chapter number without separator". I disagree. I (now) think these formats use the same rule as the "name" formats.
This ticket has not been through UXEval before, but now is a good time to clarify the "expected" behavior here, because it has consequences for other tickets such as bug 153560, bug 153710, and bug 93904, and possibly bug 153710. After OP, start with comment 11 (and a correction in comment 12). Also relevant is bug 153560, comment 9 ff.
Just from looking into the function: <H1>Chapter</H1> <H2>One</H2> Chapter name, Level 1 = "Chapter", Level 2 = "One" <H2>Two</H2> Chapter name, Level 1 = "Chapter", Level 2 = "Two" etc. If a level does not exist the field is empty, true for sublevel such as H3 or if there is no H1. We could set a maximum on the spin edit control depending on the content in this chapter. However, adding content updates the fields and you may want to see <H1><H2> with H2 empty in the header. Or H2 begin updated once it's filled with text. And the same is true for the actual chapter; the feature works well. => NAB The question is however if this is a chapter or rather a heading. "Chapter name" for a level 2 item is the heading text and not a chapter. But all is related to the current chapter, more or less. But my take is to keep the functionality as it is and rename Chapter to Heading and Chapter* to Heading*.
(In reply to Heiko Tietze from comment #14) > the feature works well. => NAB Not trying to report a bug necessarily. More like seeking an informed consensus/agreement about preferred/expected behavior. Then I can finish adjusting the labels in the relevant dialogs and try to document the behavior clearly in the tooltip and online help. There are two choices, as I understand the situation. 1. This ticket started because the original extended tip seemed to indicate that the level spinbox was to specify exactly the "outline level" of heading to be displayed. 2. Empirical investigation (bug 153560 comment 10 summarises my understanding) led to the discovery that "up to level" better describes the behavior of the spinbox, where the "rule" is: Regardless of format, select the first previous heading that has an outline level equal or less than the value specified in spinbox. I do not have an opinion about the preferred functionality (i.e., "outline level" or "up to level"). But whichever is chosen has consequences for how to label the "level" option in the field dialog (along with its tooltip and help page). Also, I believe the (≤) "rule" is more general than this Document field variable, applying also to the "level" spinbox/combobox when heading numbers are added to caption numbers and index entries. > My take: keep the functionality as it is and rename Chapter to Heading and > Chapter* to Heading*. I think this part is done already (bug 153560). Try a recent master build. If the current functionality is left unchanged, then I believe "Up to level" operates according to the rule: Regardless of format, select the first previous heading that has an outline level equal or less than the value specified in spinbox. (bug 153560, comment 12 reports an attempt to confirm via source, but would be nice with independent confirmation). Note also that some "surprises" can arise with an "up to level" option (bug 153710 and attachment 185594 [details] in bug 153560, comment 11). The first alternative (which is also what the original extended tip seemed to indicate) is to label the spinbox "Outline Level" and then only match the first heading that has the outline level specified in the spinbox. Probably easier for users to understand (and easier to document), but either way is fine with me. (If the analysis in bug 153560, comment 12 is correct, then it would be trivial to change.) Dieter gave an opinion in comment 8, but I am not sure if it corresponds to either of these two choices.
(In reply to sdc.blanco from comment #15) > I do not have an opinion about the preferred functionality (i.e., "outline > level" or "up to level"). The text is easy to understand with outline level. We should file a follow-up ticket to not show "up to" but the exact level. <H1>Heading</H1> <H3>One</H3> Chapter/Level 2 is "Heading" but should become "" Chapter/Level 1 is "Heading" Chapter/Level 3 is "One" For now let's follow your suggestions.
(In reply to Heiko Tietze from comment #16) Just to be sure that I am following correctly. > The text is easy to understand with outline level. Agree. But are you also suggesting that this (i.e., exact match of outline level) should be(come) the expected behavior? (contra your comment 14: the feature works well. => NAB) > We should file a follow-up ticket to not show "up to" but the exact level. I think that is this ticket. See bug summary. > For now let's follow your suggestions. afaict, my only suggestions were to: (a) make an informed choice about the expected behavior of the "spinbox". In that connection: 1. Is the current behavior "Inherited from OOo"? 2. Is there a use case for the current behavior? (i only have vague ideas) 3. Is there a disadvantage to adopting the "outline level" approach? 4. Does anyone know the history/intention of this control? (b) if the behavior should change, then do it now, because 1. changes have already been made recently in relevant labels, tips, help, so for the benefit of the translators, it would be better to have a final, stable version now, rather the current version, which is then changed some months later. 2. If my analysis is correct in bug 153560, comment 12, then it might be easy to make the change.
(In reply to sdc.blanco from comment #17) > But are you also suggesting that this (i.e., exact match of outline > level) should be(come) the expected behavior? (contra your comment 14: the > feature works well. => NAB) > > > We should file a follow-up ticket to not show "up to" but the exact level. > I think that is this ticket. See bug summary. Thought this was about empty fields (fine for me = NAB) not any heading greater or equal the level (which is totally unexpected and I see no reason to do so). You do some modifications for the understanding now, and that's great. I wouldn't wait for volunteers to pick up the implementation error.
(In reply to Heiko Tietze from comment #18) > any heading greater or equal the level (which is totally unexpected > do some modifications for the understanding now, > wouldn't wait for volunteers to pick up the implementation error. This situation raises a dilemma, which I do not know how to resolve. The horns of the dilemma - Make the UI/tooltip/help page correspond to: a. actual (current) behavior, or b. "intended" (?) behavior (i.e., "level" selects specified outline level) No strong opinion either way, but would prefer some decision/agreement about how to act in relation to the dilemma (in light of the actual situation). fwiw -- I would recommend a. (for reasons listed below). Better to make the UI and help reflect the current behavior (choice a.) -- but I believe that choice "breaks" with the general principle that I have learned from Mike, to document intended behavior (choice b.) -- hence the dilemma. Reasons for choice a. 1. if implementation is not likely to change (any time soon), then why invite (dupl) bug reports (such as this one), by following choice b? 2. for typical document structures (e.g., that start with outline level 1 heading, and where all the other heading paragraphs have an outline level that is -1, 0, +1 in relation to the headings before and after), then "actual" behavior is pretty close (approaching identical?) to the b. solution. 3. if there is no knowledge about the intended behavior (i.e., maybe the current behavior is not an implementation error?), and no strong use case argument for one kind of behavior vs. another (beyond what seems "logical"), then documenting a. makes it possible/meaningful (for someone else) to file a request to change the behavior, when a genuine use case arises. 4. A modest search attempt for BZ tickets about levels in relation to variables and captions gave no result => either the level control is not used much, or not problematic enough to motivate BZ tickets, or users (by trial and error) can get what they want. => if not broken, don't fix it? In sum, better to wait for a genuine use case (or knowledge of the intended design) that motivates changing current behavior to another, and to document the current behavior -- with an eye to typical use (where this ticket and bug 153560 provided more detailed documentation about current behavior).
Thought it would be clear: my take is to describe the current behavior.
(In reply to Heiko Tietze from comment #20) > Thought it would be clear: my take is to describe the current behavior. Thanks. Now it is clear. (-: @Mike Any objections? corrections? alternatives?
TL;DR (In reply to Heiko Tietze from comment #18) > Thought this was about empty fields (fine for me = NAB) not any heading > greater or equal the level (which is totally unexpected and I see no reason > to do so). You do some modifications for the understanding now, and that's > great. I wouldn't wait for volunteers to pick up the implementation error. I might misinterpret this sentence; let me first tell how I understood it, and then argue with that my understanding of the phrase. I understood it as "I see no reason for a user to set the field's level to a value greater than the existing outline level; thus, it's a user error, no change is needed, and just a documentation improvement is necessary". There *is* a reason to have this "level value greater than outline level". It is common that books have, say, chapter (let it be layout level 1) name shown on the left header, and subchapter (section; layout level 2) on the right header. In this case, it is possible that a chapter (level 1) is already started, but its subchapters (sections, level 2) has not yet (it's some introductory text). In this case, having the chapter name on the right-hand page may *or may not* be desirable. So having a way to fix the field to only show something when there is the required level is really a good thing, but at the same time, the current behavior is not a defect.
(In reply to Mike Kaganski from comment #22) > So having a way to fix the field to only show something when there is the > required level is really a good thing, but at the same time, the current > behavior is not a defect. Yes, my point was that specifying "Level 2" returns H1 if there is no H2 (yet). I'd expect it to be empty similar to the scenario you describe.
Created attachment 185864 [details] screenshot for Insert Field (document) Heading field type (In reply to Mike Kaganski from comment #22) > TL;DR Attached is a screenshot with recent changes to the "Insert Field" dialog for field type Heading (formerly Chapter). The tooltip in the screenshot documents the actual behavior. The plan is to do the same thing with field type "number range", where the "Level" option would be relabeled "Up to level" and its tooltip: ------------ Choose heading number to prepend to displayed field, where the number comes from the first prior heading whose outline level is equal to or less than the selected outline level. ------------- The issue: These changes document actual behavior (but might diverge from "intended" behavior of the "level" option). The present consensus is: better (in this particular case) to document actual behavior. Btw, your example with headers sounds like: bug 129302, comment 12