Description: Bugs concerning alphabetical index The set of procedures of inserting a field in the text for entry in the alphabetical index, including its dialogue boxes, and for generating an alphabetical index are replete with bugs. I. The dialog box 'Insert index entry' (1) I mark a string in the text and press ALT-i, ALT-x, ALT-i (Insert index entry) to mark it as an entry for the index. It is copied into the field 'Entry' of the dialogue box without being trimmed. Consequently, this entry of the Alphabetical index will be flanked by a blank or a punctuation mark and will constitute a separate entry beside the same item in pure form. (2) I mark two strings of text for entry in the index which only differ by initial capitalization. The check box 'Match case' is not marked. Nevertheless, these two entries are not merged, but printed separately in the Alphabetical index. This is unexpected and irritating. (3) In the field 'Entry', I enter a new item. In the field '1st key', the last entry of the accumulated list of 1st keys is shown as 1st key for the new entry. Since I do not want it, I have to delete it. (4) The three fields 'Entry', '1st key' and '2nd key' are in countericonic order if compared with the (sensible) order in which they are printed in the alphabetical index: here, the order is '1st key' - 'Entry'. Thus, apparently '1st key' means 'Main entry' and 'Entry' means 'Subentry'. The order and names of these fields should consequently be: 'Main entry' '1st level subentry' '2nd level subentry'. (5) The buttons 'Insert' and 'Close' are in the wrong order. The button 'Close' must be the last one. (6) The letter by which the button 'Insert' may be presssed is 'n'. It must be 'i', as in all the other buttons with this function. II. The dialog box 'Edit index entry' (7) 'Close' must be the last button. III. Accessing index fields I mark a string in the edited file and trigger 'Insert index entry'. The selected word is offered for Entry. If I accept it, the selected string in the text gets a grey background, with the consequence that it can be right-clicked as a whole. Okay. (8) If I write anything different in the Entry field, my selection of a string in the file is ignored; it gets no gray shading. This happens even if my entry differs from the selected string only by initial capitalization or if the selected string is in the '1st key' field instead of the 'Entry' field. Instead, the algorithm stipulates the position preceding the string in question as the insertion point for the field and marks it by half a blank space with gray background. If later I want to access this field to edit it, hitting the half blank space with the cursor is a test of patience. The clickable area must be much wider. (9) If the index field has been inserted in a table cell, there is no way to right-click it, i.e. the index field cannot be accessed at all. (10) Index fields are displayed by the same grey shading which is used for other field types. Consequently, if an index field coincides with, or is immediately adjacent to, another field, it is indiscernable. Use a different color for the shading. IV. Generation of Alphabetical Index (11) If the index field has been inserted in an automatically numbered heading, the index entry is sometimes (not reliably reproducible) generated with the number preceding it, which is not wanted. As a result, the most important candidates for entries in the alphabetical index, viz. chapter headings, cannot be used for this purpose. (12) The page numbers printed in the index have the same referential function as the page references inserted by ALT-i, ALT-r, 'Refer using page number'. Like these, they should work as hyperlinks. They are, however, dead. (13) In the style 'Index', font size should be 90%. (14) The style 'Index 2' inherits from the style 'Index'. Correct. The style 'Index 1' does not. Wrong. Steps to Reproduce: 1. Mark a text string in the document. 2. Insert - Table of Contents and Index - Index Entry 3. Edit 'Entry' field. Actual Results: All the results specified in the 'Description' box. Expected Results: More systematic and user-friendly interface. Reproducible: Always User Profile Reset: No Additional Info: All of the above bugs concern the same module of LO Writer. I join them in a single report to alleviate the task of the developer occupying himself with them. If anybody thinks this report must be converted into fourteen separate bug reports, please feel free to do so.
Having all of these bugs in the same report hampers dealing with them, so let's start the process of splitting them into separate reports. (In reply to Christian Lehmann from comment #0) > I. The dialog box 'Insert index entry' > > (1) I mark a string in the text and press ALT-i, ALT-x, ALT-i (Insert index > entry) to mark it as an entry for the index. It is copied into the field > 'Entry' of the dialogue box without being trimmed. Consequently, this entry > of the Alphabetical index will be flanked by a blank or a punctuation mark > and will constitute a separate entry beside the same item in pure form. Your description is not clear. When you mark the string, do you mean that you include whitespace or punctuation marks? I certainly can't reproduce without explicitly including such characters, so is this like a feature request to provide trimming for when we accidentally select blanks or punctuation? > (2) I mark two strings of text for entry in the index which only differ by > initial capitalization. The check box 'Match case' is not marked. > Nevertheless, these two entries are not merged, but printed separately in > the Alphabetical index. This is unexpected and irritating. Steps are again not clear. I can't find 'Match case' anywhere. I can't reproduce the issue, the entries are not printed separately in my testing. > (3) In the field 'Entry', I enter a new item. In the field '1st key', the > last entry of the accumulated list of 1st keys is shown as 1st key for the > new entry. Since I do not want it, I have to delete it. Could be created as a new report while involving UX team. > (4) The three fields 'Entry', '1st key' and '2nd key' are in countericonic > order if compared with the (sensible) order in which they are printed in the > alphabetical index: here, the order is '1st key' - 'Entry'. Thus, apparently > '1st key' means 'Main entry' and 'Entry' means 'Subentry'. > The order and names of these fields should consequently be: > 'Main entry' > '1st level subentry' > '2nd level subentry'. This is a bit of a UX challenge. If I get your proposal correctly, you're saying '1st key' becomes 'Main entry' '2nd key' becomes '1st level subentry' 'Entry' becomes '2nd level subentry' The extended tooltip of '1st key' is: Makes the current selection a subentry of the word that you enter here. For example, if you select “cold”, and enter “weather” as the 1st key, the index entry will be “weather, cold”. The extended tooltip of '2nd key' is: Makes the current selection a sub-subentry of the 1st key. For example, if you select “cold”, and enter “weather” as the 1st key and “winter” as the 2nd key, the index entry will be “weather, winter, cold”. I guess the idea behind the current naming is that the keys will not be used every time. Your proposal would therefore be confusing in this simpler use case. Also, the proposed naming of 'Main entry' conflicts with the checkbox found in the same dialog. In Writer guide, 'Main entry' is explained as: When the same term is indexed on several pages, often one of those pages has more important or detailed information on that topic, so you want it to be the main entry. To make the page number for the main, or most important, entry stand out, select this option and then define the character style for the page number of a main index entry to be bold, for example. https://books.libreoffice.org/en/WG252/WG2515-TOCsIndexesBiblios.html#toc18 > (5) The buttons 'Insert' and 'Close' are in the wrong order. The button > 'Close' must be the last one. Can be valid. This is at the moment apparently dependent on the UI used. With gtk UI, 'Close' is the last one. > (6) The letter by which the button 'Insert' may be presssed is 'n'. It must > be 'i', as in all the other buttons with this function. The 'i' accelerator is occupied by 'Index' in the dialog, so I guess you propose to swap the keys. > II. The dialog box 'Edit index entry' > (7) 'Close' must be the last button. Same comment as for 5. > III. Accessing index fields > I mark a string in the edited file and trigger 'Insert index entry'. The > selected word is offered for Entry. If I accept it, the selected string in > the text gets a grey background, with the consequence that it can be > right-clicked as a whole. Okay. > > (8) If I write anything different in the Entry field, my selection of a > string in the file is ignored; it gets no gray shading. This happens even if > my entry differs from the selected string only by initial capitalization or > if the selected string is in the '1st key' field instead of the 'Entry' > field. Instead, the algorithm stipulates the position preceding the string > in question as the insertion point for the field and marks it by half a > blank space with gray background. > If later I want to access this field to edit it, hitting the half blank > space with the cursor is a test of patience. The clickable area must be much > wider. Something that could help with this is https://bugs.documentfoundation.org/show_bug.cgi?id=164864 "navigator should show index entries" I guess widening is something the UX team could discuss. > (9) If the index field has been inserted in a table cell, there is no way to > right-click it, i.e. the index field cannot be accessed at all. Accessing via double-clicking or right-click context menu works fine for me when the field is in a table cell. Tested on Windows and all Linux UIs. > (10) Index fields are displayed by the same grey shading which is used for > other field types. Consequently, if an index field coincides with, or is > immediately adjacent to, another field, it is indiscernable. Use a different > color for the shading. Something for the UX team. > IV. Generation of Alphabetical Index > > (11) If the index field has been inserted in an automatically numbered > heading, the index entry is sometimes (not reliably reproducible) generated > with the number preceding it, which is not wanted. As a result, the most > important candidates for entries in the alphabetical index, viz. chapter > headings, cannot be used for this purpose. Reliable steps would be great. > (12) The page numbers printed in the index have the same referential > function as the page references inserted by ALT-i, ALT-r, 'Refer using page > number'. Like these, they should work as hyperlinks. They are, however, dead. This seems relevant: https://bugs.documentfoundation.org/show_bug.cgi?id=71385 "Alphabetical Index cannot generate hyperlinks" > (13) In the style 'Index', font size should be 90%. Something for the UX team. > (14) The style 'Index 2' inherits from the style 'Index'. Correct. The style > 'Index 1' does not. Wrong. Not reproduced. Created an index entry with 1st and 2nd keys, inserted index. Changed font family of 'Index' style. All the child styles inherited it. Please clarify.