Issue 125750 - Wrong chapter title in running header after the first page of endnotes
Summary: Wrong chapter title in running header after the first page of endnotes
Status: UNCONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: formatting (show other issues)
Version: 4.1.1
Hardware: All All
: P3 Normal with 2 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-14 17:50 UTC by Kartik Subbarao
Modified: 2024-04-04 14:07 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
zip file containing rh.odt and rh.pdf (44.57 KB, application/zip)
2014-10-14 17:50 UTC, Kartik Subbarao
no flags Details
zip file with: EndnoteHeader.odt, ScreenshotBeforeReopen.PNG and ScreenshotAfterReopen.PNG (710.25 KB, application/x-zip-compressed)
2017-04-29 20:56 UTC, Gabi Kis
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Kartik Subbarao 2014-10-14 17:50:44 UTC
Created attachment 84062 [details]
zip file containing rh.odt and rh.pdf

Please see the attached files rh.odt and rh.pdf. 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.

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).
Comment 1 Kartik Subbarao 2014-10-14 17:52:09 UTC
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 2 Gabi Kis 2017-04-29 20:56:10 UTC
Created attachment 86042 [details]
zip file with: EndnoteHeader.odt, ScreenshotBeforeReopen.PNG and ScreenshotAfterReopen.PNG

Configurations: 
AOO413m1 (Build:9783) - Rev. 1761381, Windows 10
AOO411m6 (Build:9775) - Rev. 1617669, Windows 10

Using the attached document (rh.odt) the issue is reproduced on both configurations.

When tried to reproduce the issue creating a new document from scratch the behavior is slightly different (different endnote chapter names on different pages, same behavior on both configurations):
Steps:
 1. Create a new document
 2. Add two Heading1 titles (“Introduction” and “Chapter1”, with some space between them)
 3. After the second title add multiple endnotes, until you get two endnote pages (Insert -> Footer/Endnote, type: Endnote)
 4. Add header for the endnote pages (Insert -> Header -> Endnote)
 5. Add Chapter name in Header (Insert -> Fields -> Other -> Tab: Document, Type: Chapter, Format: Chapter name)

Actual result: the header chapter name on the first page is “Introduction” and on the second page is “Chapter1” – see attached screenshot (ScreenshotBeforeReopen.PNG)

Expected result: the header chapter name should be “Chapter1” for all endnote pages.

After I save, close and reopen the document the header chapter name reverses for the two endnote pages (for the first endnote page is “Chapter1” and for the second endnote page is “Introduction”) – see attached document: EndnoteHeader.odt (or ScreenshotAfterReopen.PNG)

To reproduce using the attached EndnoteHeader.odt document:
 1. Add a few empty lines (<enter>) in “Chapter1” so that the endnotes page get to a new page
 2. Delete the empty lines entered
the endnotes get to page 2 and the Header title changes for the first endnotes page from “Chapter1” to “Introduction” and for the second endnotes page from “Introduction” to “Chapter1”.
After save, close and reopen the document, the header chapter name reverses back for the endnote pages.

See also (related bugs):
Issue 70429 - endnotes and headers
Issue 118020 - Endnotes take the header from the previous section before current
Comment 3 Kartik Subbarao 2024-04-04 14:07:34 UTC
FYI this has been fixed in libreoffice now:

https://git.libreoffice.org/core/commit/746b21760b911860c7ac497f10ab07d60111e867

Looking at the Apache OpenOffice code, it looks this corresponds to the following line in main/sw/source/core/fields/expfld.cxx:

https://github.com/apache/openoffice/blob/trunk/main/sw/source/core/fields/expfld.cxx#L246