https://bugs.freedesktop.org/show_bug.cgi?id=81012
--- Comment #6 from Kartik Subbarao <[email protected]> --- 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. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
