[Issue 125750] New: Wrong chapter title in running header after the first page of endnotes

[bu...@apache.org]

https://issues.apache.org/ooo/show_bug.cgi?id=125750

          Issue ID: 125750
        Issue Type: DEFECT
           Summary: Wrong chapter title in running header after the first
                    page of endnotes
           Product: Writer
           Version: 4.1.1
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: formatting
          Assignee: issues@openoffice.apache.org
          Reporter: subbarao@computer.org

Created attachment 84062
  --> https://issues.apache.org/ooo/attachment.cgi?id=84062&action=edit
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).

-- 
You are receiving this mail because:
You are the assignee for the issue.
You are watching all issue changes.

[Issue 125750] Wrong chapter title in running header after the first page of endnotes

[bu...@apache.org]

https://issues.apache.org/ooo/show_bug.cgi?id=125750

--- Comment #1 from Kartik Subbarao <su...@computer.org> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the issue.
You are watching all issue changes.