Bug 81012 - FORMATTING: Wrong chapter title in running header/footer after the first page of endnotes
Summary: FORMATTING: Wrong chapter title in running header/footer after the first page...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Writer-Header-Footer Fields
  Show dependency treegraph
 
Reported: 2014-07-07 18:56 UTC by Kartik Subbarao
Modified: 2023-05-13 15:29 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
zip file containing rh.odt and rh.pdf (44.57 KB, application/zip)
2014-07-07 18:56 UTC, Kartik Subbarao
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kartik Subbarao 2014-07-07 18:56:46 UTC
Created attachment 102388 [details]
zip file containing rh.odt and rh.pdf

Problem description: On the right page header, the Chapter Title field is mis-inserted as the title of the *first* chapter instead of the *current* chapter. This occurs after the first page of endnotes at the end of the section that contains the chapter.

Steps to reproduce:
1. See attached files rh.odt and rh.pdf
2. Note that the chapter title in the header on page 7 is fine (Chapter2), whereas on page 9, it wrongly reverts back to the title of chapter 1 (Introduction)
              
Operating System: All
Version: 4.2.5.2 release
Comment 1 Kartik Subbarao 2014-07-10 15:08:58 UTC
It appears that this bug goes at least as far back as 3.3.0.4. That was the earliest version that I was able to download and test from the download.documentfoundation.org site.
Comment 2 Andrew Pitonyak 2014-07-11 01:56:55 UTC
I was able to reproduce this bug using version 4.2.5.2 on my Fedora Linux system.

The problem appears to be related to the end notes, since, when I make the document longer, the part containing the incorrect field value is only where there are end notes. The irony is that the end notes are from chapter 2 and the pages with the end notes show chapter 1.

I added a third chapter in my copy of the test document, and the point where the end notes begin is properly displays the chapter in which the end notes live, but, after the first page break this is no longer true!
Comment 3 Andrew Pitonyak 2014-07-11 02:02:19 UTC
Side note, same behavior in the footer (no surprise).
Comment 4 Andrew Pitonyak 2014-07-11 02:09:59 UTC Comment hidden (obsolete)
Comment 5 Jorendc 2014-07-16 19:58:35 UTC
(In reply to comment #2)
> I was able to reproduce this bug using version 4.2.5.2 on my Fedora Linux
> system.

Lets mark it as NEW then :-)

Kind regards,
Joren
Comment 6 Kartik Subbarao 2014-09-26 22:59:12 UTC
Looking at the source code and walking through it with gdb, here's what I think is causing the problem.

The Chapter Name field in the header of a page is determined by looking at the first text node in the body of that page. The Index of that text node (returned via the GetIndex() function) is compared to the Index of all of the Chapter Headings (as stored in the Outline array). The chapter with the closest Index value lower than the text node is chosen (by SwNode::FindOutlineNodeOfLevel() in node.cxx). For example, let's say that the heading for chapter 1 has an Index of 22, the heading for chapter 2 is 25, the heading for chapter 3 is 50, and the first text node on our page of interest is 45. Since chapter 2 has the closest index value lower than the text node, its name goes into the header.

Usually, this logic works fine. From what I can tell, the Index value generally correlates to parsing sequence. The Index value for a chapter heading is normally lower than the Index value for the text nodes in that chapter, since the heading is parsed first. However, endnotes seem to be an exception to this. In a document that I tested with chapter 1 and 2 having the above index values, the first endnote of chapter 2 has an Index of 4, and the second endnote has an Index of 7.

This is what causes the problem. When endnote 2 appears as the first text node on a page, its Index value of 7 is below the chapter 2 heading Index of 25, so that page is not seen as being part of chapter 2.

Now, why does the name for Chapter 1 show up as the header on our page of interest? After all, the endnote Index value of 7 is also less than chapter 1's Index value of 22, and should be rejected by some sanity check. It turns out that there is such a sanity check (lines 783-784 of node.cxx), but that sanity check uses a *different* comparison metric. Instead of using the Index value returned by GetIndex(), it uses the result of the Top() function in the page frame, which is the absolute Y value. Endnote 2 of chapter 2 reports a much higher Y value than the heading of chapter 1, so the sanity check passes this and chapter 1's name ends up going into the header.

I don't know what the best fix is to this problem, but I can suggest some things to consider.

1) SwNode::FindOutlineNodeOfLevel() currently uses two different metrics to compare nodes -- Index value and absolute Y value. Would it be better to standardize on just one of these metrics? On the surface, it looks like standardizing on the absolute Y value to fix the bug might require less work overall, but I don't know the code well enough to say for sure.

2) Alternatively, can/should the Index values of endnotes be updated so that they conform to the assumption that SwOutlineNodes::Seek_Entry is making (i.e., that later nodes have higher values)? From an architectural perspective, it would probably be good to clarify whether this property of Index values is something that other parts of the code can rely on, or whether they should not count on it.
Comment 7 QA Administrators 2015-10-14 19:56:21 UTC Comment hidden (obsolete)
Comment 8 Kartik Subbarao 2015-10-16 23:16:04 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2016-11-08 11:04:40 UTC Comment hidden (obsolete)
Comment 10 Kartik Subbarao 2016-11-08 16:26:28 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2017-11-09 07:43:11 UTC Comment hidden (obsolete)
Comment 12 Kartik Subbarao 2017-11-09 14:23:09 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2018-11-10 03:52:05 UTC Comment hidden (obsolete)
Comment 14 Kartik Subbarao 2018-11-10 17:06:54 UTC Comment hidden (obsolete)
Comment 15 QA Administrators 2019-11-11 03:37:20 UTC Comment hidden (obsolete)
Comment 16 Kartik Subbarao 2019-11-15 20:55:51 UTC
This bug is still present in LibreOffice 6.2.8.2.
Comment 17 Timur 2021-05-12 12:50:21 UTC
Repro 7.2+. Discussion is in bug 129302.
Comment 18 QA Administrators 2023-05-13 03:19:04 UTC Comment hidden (obsolete)
Comment 19 Kartik Subbarao 2023-05-13 15:29:10 UTC
This bug is still present in LibreOffice 7.5.2.2