Created attachment 109493 [details] Wrong Field reference when heading is in a frame If headings are in a frame, and you want the Chapter Name displayed in your page header, only the chapter name from the last frame's heading is displayed throughout the whole document. Indexes however can be created with no problems, and in the Fields' Cross-References all the headings appear as well. There is a document attached that helps you to understand the error.
Confirmed by opening the file on Windows -> NEW. Win 7 64-bit Version: 4.4.0.0.alpha2+ Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827 TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08
In addition to my initial report: if you use different levels of headings, and some of them are placed in a frame, they don't show up in a proper order in the Navigator. Sub-headings appear to be disconnected from their preceding level (e.g. chapter). The same goes for the Cross-References in the Fields dialog box. Still, creating an index for your document works fine. I didn't open a new bug for this because I think both issues are related.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
Created attachment 122628 [details] Problems with Chapters in frames, added sub-chapters do demonstrate related Navigator issues Confirmation that the bug still exists. I have added sub-chapters to the test document to demonstrate the issues in Navigator as described in an earlier post. Version tested: 5.1 Linux AMD64
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
Created attachment 142218 [details] Example of wrong numbering when heading is in a frame Problem is still present on 6.0.4. In addition to the original description, there is also a big problem if you use outline numbering. For example, consider a document where you have Heading 1 → numbered as # Heading 2 → numbered as #.# Heading 3 → numbered as #.#.# And the content of your document is 1. First heading 1 (normal text) 2. Second heading 1 (normal text) 2.1 A heading 2 as normal text 2.1.1 A heading 3 as normal text [1.1.1 A heading 3 inside a frame] ← wrong numbering! See attached file.
Dear Frank Berke, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Problem still present in Version: 7.1.0.3. (see Comment 6, too)
Repro with attachment 142218 [details] Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: d34d1db55978bdcff082af1e0f75b18fa6fc94f4 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: CL There are many different issues in this ticket, but no evaluation of whether headings inside of Frames should participate in the outline structure of the document. Might be worth asking the Design Team to confirm that the expectations here are valid for Frames. To do that: Add 'needsUXEval' to Keywords and libreoffice-ux-advise@lists.freedesktop.org to CC list
Cannot wrap my mind around a frame with heading moved to some other position- neither to have it in the header/footer area. Why the heck would you do that? If the chapter needs to be present in the header a reference is the way to go. So my first idea is to block outlines in special sections. But I see no clear way to do so as it requires to block applying a style linked to an outline - but no other style. In respect to the sorting order at the Navigator we do wrong in either way. We show in the Navigator somehow what you see in the document. Somehow since "Chapter 1.1" comes before framed "Chapter One", which then contains 1.1.1 ff. Btw, use Tools > Chapter Numbering to get the true level. Maike, Jim, what do you think?
It's a confusing concept: headings in frames. You can anchor several frames to a single paragraph; which chapter that paragraph belongs then? Or if the frame is anchored to a character or as character, which part of the paragraph belongs to which chapter? Or when you reorder chapters using Navigator, how should things move? I don't know what would be sane here. I don't think we can disable some paragraph properties in some special areas; ignoring them there could be a reasonable options - but potentially breaking existing documents and creating much pushback (from users who consider current awkward partial state of correct index generation good enough, and maybe also helping interoperability). CCing Miklos, maybe he has better ideas.
Referring to attachment 'Problems with Chapters in frames, added sub-chapters do demonstrate related Navigator issues' The reason for 'Chapter 1.1' showing in the Headings entries before 'Chapter One' is both are considered to have the same document Y position. The Y position of headings in a frame are determined by the frame's anchor position. The frame containing 'Chapter One' is paragraph anchored at 'Chapter 1.1' paragraph. In this case alphabetical sorting is used. Changing 'Chapter One' to 'Chapter 1' will show 'Chapter 1' before 'Chapter 1.1' in the Headings entries. When the frame anchor is moved into the header paragraph 'Chapter One' is placed before 'Chapter 1.1'. Currently chapters in a frame are ordered alphabetically because the frame anchor position is used to determine document position for these. Why the frame is considered to be in the header when it is anchored to the first paragraph in the document body I do not know.
Many good reasons to keep the current state and the use case is far-fetched if not invalid. Unless Miklos has a better idea I resolve as NAB.
No better idea, putting headings inside frames sound like a garbage in -> garbage out case to me. :-)