Insert - Field - More Fields (Ctrl-F2) - Document tab - Type "Chapter" Proposal: Type Format Chapter -> Heading (all) Chapter -> Heading Reason: In LO, chapter is a paragraph with outline level 1, but this dialog allows a user to select which outline level is used. This means that "chapter" is technically incorrect in this dialog (and does not highlight the fact that this variable can be used for headings at any outline level, or gives dissonance with the Level control).
Now that "Chapter Numbering" is transitioning to "Heading Numbering" (bug 153549), it is relevant to call this ticket to UXEval attention.
Some of the problems reported in bug 147004, bug 93904 and bug 92805 may be addressed by improved labeling/tooltip to give better expectations about "intended" behavior, but I have not tried to evaluate whether there are issues in those three bugs that go beyond labelling/documentation.
If label is changed, then updating needed for "Insert Edit" and "Edit Field" help pages. https://help.libreoffice.org/7.6/en-US/text/swriter/01/04090001.html https://help.libreoffice.org/7.6/en-US/text/swriter/01/02140000.html
Also "General" Options help for LibreOffice Writer https://help.libreoffice.org/7.6/en-US/text/shared/optionen/01040900.html
(In reply to sdc.blanco from comment #1) > Now that "Chapter Numbering" is transitioning to "Heading Numbering" (bug > 153549), it is relevant to call this ticket to UXEval attention. Don't think you need a stamp on every single modification. The reasoning makes sense. I suggest to create a META ticket under that all of these modifications could be collected. Interested persons may find easily what has changed and why.
Maybe not a "META"-meta ticket but some ticket that can be used for patches - or as breadcrumb through bugzilla.
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/842ed5e6b02939ca57db90f08ce5877836ae45ed tdf#153560 "chapter" -> "heading" for Type and Format and adjust "level" label It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/9b4f3d78786ba6b1d014dfb6075b3245cd5f7bf2 tdf#153560 update changes "Chapter"->"Heading"; "Level"->"Up to level"
New problem discovered in relation to "Up to level" The two formats ("heading number"; "heading number without separator") use the immediately prior heading, where the "up to level" option controls how many levels of the heading number are displayed. (at present the tooltip/extended tip and help is written in this way) The new discovery is in relation to the other two formats for the "Heading" field type ("heading contents"; and "heading number and contents"). Based on extensive experiments, my hypothesis for its rule: Display the heading contents for the first prior heading whose outline level is less than or equal (≤) than the number specified in "up to level". For example, if inserted field has an "up to level" of "5", then the first immediately prior paragraph with level 5 or less is shown (i.e., any immediately prior headings with outline level 6 or greater are ignored). This behavior contrasts with the "number" formats, which would select the first heading (regardless of outline level). (attachment 185589 [details] gives a demonstration, which can be used for testing) Furthermore, with "heading number and contents", unlike the "number" formats, there is no control over how many outline levels of the heading number shown. Before trying to make further adjustments in help/tips, let me check what is the "intended" behavior here? An immediate hypothesis is that the "content" cases are a bug (and a new ticket should be filed), it is hard (for me) to imagine a use case that would need this "feature?"
(In reply to sdc.blanco from comment #9) > The two formats ("heading number"; "heading number without separator") use > the immediately prior heading, where the "up to level" option controls how > many levels of the heading number are displayed. Correct description of appearance, but for wrong reason! > other two formats for the "Heading" field type ("heading contents"; and > "heading number and contents"). > Display the heading contents for the first prior heading whose outline level > is less than or equal (≤) than the number specified in "up to level". This is the correct reason. > Furthermore, with "heading number and contents", unlike the "number" > formats, there is no control over how many outline levels of the heading > number shown. False issue. I misinterpreted the levels option as controlling how many levels are shown (which is empirically correct, but an artifact of how the "prior numbered heading" is selected). The option shows the number and contents of the first header that satisfies the (≤) rule. > An immediate hypothesis is that the "content" cases are a bug Possibly. To summarize: 1. The "level" control has the same behavior for all four formats of the "Heading" field type. 2. Regardless of format, the field selects the first previous heading that has an outline level equal or less than the value that is specified in the "level" spinbox. (maybe that is the bug? already filed: Bug 147004) If deemed to be a bug, then "up to level" should be changed to: "outline level". 3. I now have the hypothesis that "level" in "Numbering by Chapter" for caption numbers follows the same (≤) rule (which may also be a bug, if it does not use the same code), but I could not "see" that problem before now (with my empirical method), because that dialog only shows numbers, not contents.
Created attachment 185594 [details] test file to demonstrate "rule" for Numbering by Chapter (In reply to sdc.blanco from comment #10) > 3. I now have the hypothesis that "level" in "Numbering by Chapter" for > caption numbers follows the same (≤) rule The attachment provides some empirical support for that hypothesis. It also has some instructions that shows if the specified level is not found, then the first heading paragraph (at the top of the document) is used -- no matter what level (i.e., a new problem/bug?). And the same effect/rule also seems to be happening with the CI widget in user-defined index (which also has an "Evaluate up to level" ... (see bug 153710). It starts to look like there is a consistent "rule" used across the different situations (with index, variable, caption), but I guess not so surprising, given that they are all using a variable field. (but again, this is all empirical discovery, have not tried to follow the source code.)
(In reply to sdc.blanco from comment #11) > have not tried to follow the source code. Best guess: SwCursorShell::GetOutlinePos https://opengrok.libreoffice.org/xref/core/sw/source/core/crsr/crstrvl.cxx?r=db115bec#1314 Line 1329 is consistent with the (≤) rule (and relevant to bug 147004 and bug 153710) Line 1340 may explain (from comment 11 "if the specified level is not found, then the first heading paragraph (at the top of the document) is used -- no matter what level" (Demonstration in test file (attachment 185594 [details]), where level 10 heading (at first heading) is shown in Figure caption number. Instructions in the frame in the test file). It seems like this corner case was not considered. If these guesses are correct, then it seems like this function is being used in the Caption Options (for Insert Caption), Heading (document) field, Heading Info (in Entries tab). Finally, if the analysis up to here is correct (along with a decision about whether bug 147004 is a bug), then I understand what labels/tooltips are needed in these different dialogs/help pages. Hoping now for some confirmation or correction...
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1bede0887faa1eec94cff66cf0daa0eed66750ab tdf#153560 "up to level" also selects field contents It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/e87fd6170e4836d6fb426470a97d78c87659970a tdf#153560 corrections to "up to level" and "Format"
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/b119b55661646266f6432addfa59f3de24925315 tdf#153560 (tdf#153748) update "up to level"
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/142696bd75353a8b1fa23c6aae08b0d18e807546 tdf#153560 adjust heading levels for "Up to level" and "Offset"
Labels changed in dialog, tooltip added to "Up to level", extended tip revised, relevant help pages updated. Closing as FIXED.