https://bugs.documentfoundation.org/show_bug.cgi?id=168556
--- Comment #2 from ajlittoz <[email protected]> --- > 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. -- You are receiving this mail because: You are the assignee for the bug.
