Created attachment 202972 [details] Wrong fallback behaviour when target level missing Version: 25.2.6.2 (X86_64) Build ID: 520(Build:2) CPU threads: 4; OS: Linux 6.16; UI render: default; VCL: kf6 (cairo+wayland) Locale: en-US; UI: en-US Calc: threaded The attached sample file exhibits a distorted outline structure (this is logically "bad"), which can be schematically described as: - level-3 heading - level-2 heading - level-1 heading - standard outline structure from there on The header should echo the current level-1 heading. For this, a field is inserted in the header, taken from Document tab, "Heading" type and limited to level 1. In my understanding, this field captures the outline state in the first paragraph of the page. If the requested level is larger then the level in the first paragraph, a progressively shallower level is probed until levels are exhausted, in which case a "void" value is returned. If it is smaller, the current stack is used and I assume that missing levels are handled similarly to what I stated above. The sample file begins with a level-3 heading without preceding level-1 or level-2. The header requests level-1, which does not exist. According to my understanding, level-1 request should be popped to level-0, i.e. no heading at all, and return "void" which would result in a blank header. Instead of this, the first known level, i.e. level-3 is returned. But this interpretation of "first available level" is wrong: I added a page break after the level-2 heading to see how the header would eventually change. It didn't. Though first paragraph is now under a level-2 heading, the header still displays level-3! In addition, numbering is not what I expect but this may be an inherent behaviour of list styles. I start directly at level-3. Despite of this, level-1 and level-2 in the list numbering are implicitly initialised to their starting values. The consequence is the "First level-1" is numbered 2 instead of the expected 1. I know that the document has a faulty structure (it is inspired by a "bad" document attached on AskLO), so the fix would be "user, please, correct the structure". At least, a clarification is needed on heading field capture behaviour when the requested field does not exist. The "standard" use case is header suppression at start of a document while still allowing hierarchical divisions (without numbering -- numbers were added in the sample just to see more clearly what's happening). And since the level-1 item does not exist, numbering sequence start for level-1 should be deferred until the first level-1 is met. I admit this makes sense for headings but is probably totally wrong for "ordinary" numbered lists: having "void" numbers for missing higher levels would be quite confusing (though something like "..1 First level-3" could be acceptable and would happen only at the beginning of a list) Expected results: - no heading returned for missing requested and shallower levels - if not possible, strict application of the algorithm to return effective shallowest level active at start of page
Ajilttoz, I'm not sure, if I could follow for 100%, but could you please check if the problem is covered by bug 129302? => NEEDINFO
> please check if the problem is covered by bug 129302 No. Bug 129302 requests a change in outline probing time. Presently, this occurs on first line in page, i.e. when the header is output. IMHO, this is the simplest way to do it and needs no cache. Proceeding differently might defer header generation until reaching end of page and, if data gathered overflows space which has been reserved for it, this would cause a full reflow of the page with a change in location of end of page. In extreme case, this page end change would invalidate gathered data (like field capture or footnote layout) and we enter an infinite loop. My report is related to heading capture selection in field. When I insert a field for heading level 3, I don't expect to receive data from levels 4-10. When there is no level 3 at the point of reference (first line of page in case of header), the fallback procedure is to test for level 2 and again if there is none for level 1 before declaring failure returning "void". This makes sense. Now, the attachment is "pathological". It starts at level 3 without preceding levels 1 and 2. The field requests level 1. Then there is at least a bug in the fact that I get level 3 data. I expect that levels deeper than the one requested are NOT scanned for contents. Here, since levels 1 and 2 do not exist at start of page, I expect a "void" value. BUT, there is obviously a problem. Headings are numbered with a list style, i.e. a multi-level counter. There can't be a "void" number in shallower level of a standard numbered list style. I found a partial workaround with a "mixed" list style where shallow levels are bullet and deeper levels numbers. But, once again, this leads to a pathological style: bullets are not displayed and are replaced with "void" in deeper levels where numeric numbering is in effect. Anyway, there is something really weird in the attachment. If you add Body Text paragraph before the first Heading 3, contents of the header does not change ! This goes against the "first line dictates captured outline hierarchy" principle. I am perfectly aware that the outline structure of the attachment is faulty. I'd understand you dismiss it as such, recommending to fix the outline structure. However, I politely ask that you check Writer does not scan outline levels larger than the one requested in the field. The field level is "cap" not-to-be-exceeded in any circumstances. Presently, there are cases where first level available is returned instead of the orderly one.
[Automated Action] NeedInfo-To-Unconfirmed
Created attachment 205331 [details] "Up to level" setting not honored for Heading references Confirmed: The chapter field does not respect the configured outline level: The heading field reference returns deeper outline levels when the requested level doesn't exist, instead of returning void. Steps to reproduce: 1. Create a new Writer document 2. Apply "Heading 3" style to the first paragraph (without any preceding Heading 1 or Heading 2) 3. Add some Heading 2, then Heading 1, then normal outline structure below 4. Insert → Header and Footer → Header → Default Style 5. In the header, Insert → Field → More Fields → Document tab 6. Select Type: "Heading", Format: "Heading number and contents", set "Up to level" to 1 7. Click Insert, then Close Actual result: The header displays "1.1.1 Heading label" (outline level: 3) Expected result: The header should be blank (void) because: - Level 1 does not exist at this point - Level 2 does not exist at this point - Fallback should stop here, not scan deeper levels "Up to level" should define a ceiling, not trigger a search into deeper levels. Search up (shallower), not down (deeper). Return blank if no level found. Version: 25.8.5.1 (X86_64) Build ID: cde5f182e321816108385dd3739c4295be919062 CPU threads: 16; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win Locale: en-AU (pl_PL); UI: en-US Calc: CL threaded