Created attachment 191229 [details] Index entries for TOC not cross-referenceable LO 7.6.3.1 Linux 6.6.3, KDE Plasma desktop (Qt-based) -- Fedora 39 Version: 7.6.3.1 (X86_64) Build ID: 60(Build:1) CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb) Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded TOC can be extended with special index entries where the target table is chosen from a drop-down menu. These entries are assigned an outline level so that they appear and are formatted at the right level. They behave like headings and can be used for special effect such as run-in headings, even several in the same line. The only difference with paragraph-headings is they can't be numbered with a list style because a list style attaches to a paragraph not a portion of a line. However, when cross-referencing text, index entries are not listed under the Headings category and cannot therefore be referenced. Even if they have (presently) no chapter number, why can't they be listed among the headings?
Ajlittoz, thank you for reporting the bug, but I'm afraid, I don't understand everything. Index entry is not a heading and so it is not expected to appear as selectable heading in cross-reference tab of the fields dialog. I understand, that your aim is to insert a field with a cross reference to an index entry. So possible solution would be to add index entry as new type in cross-reference dialog. Does this makes sense to you? => NEEDINFO
(In reply to Dieter from comment #1) > Index entry is not a heading Granted. But the TOC dialog allows to create a TOC from various sources: headings, additional styles and index entries. >and so it is not expected to appear as > selectable heading in cross-reference tab of the fields dialog. I expected that when this last option was ticked, index entries would appear in the cross-reference dialog the same as heading items when type Headings is selected. I was exploring a way to create unnumbered inline/run-in headings, which is not a present feature. The alternate approach is to add hidden headings and visible cross-reference where the run-in should be located. This is tricky, error-prone and not simple. The "index-heading" looked to me an "elegant" workaround. Indeed, it works quite nicely. You only need to select "Table of Contents" for the destination of the index entry. This completely separate the "traditional" index entries from this TOC usage. Since the "special" index entries are tagged "Table of Contents" at creation time, they can't be confused with alphabetical entries which will go into the Alphabetical Index. This should be enough to be able to include them in the cross-reference headings list in order to make them cross-referenceable like the other "standard" headings. > So possible solution would be to add index entry as new type > in cross-reference dialog. Does this makes sense to you? This would create more problems, I think. Semantically, cross-references for "normal" index entries *IS* the alphabetical index and it was invented for that purpose. My request was only about those "special" index entries designated to be part of TOC. The request is related to Run-in/inline headings. If such a feature is ever implemented, my request becomes pointless. Among other points, there is the difficulty to number the index-TOC entries. It can partially be done with a number range prefixed with outline level. But number ranges can't be reset. Therefore, the index entry number can't be reset when switching to another chapter, sub-chapter, … This requires one number range per chapter, sub-chapter, … which is not manageable at all and makes maintenance very difficult when blocks of text are moved because the number range must be changed to match the new context.
[Automated Action] NeedInfo-To-Unconfirmed
So let's treat it as enhancemtn request an ask design-team.
The document contains H1 "This is a level 1..." some index entry H2 "Lorem ipsum" the Toc with these three items a cross-reference to the H2 I understand the request/s as * allow cross-reference to index entries (with the argument that it can be added to the ToC) I don't understand * "It (the index entry) is assigned an outline level" (the field is not a paragraph, the H2 "Lorem" is not the IE but you added a cross-reference later) * an index entry lacks many properties of standard headings (how can you compare the two things?) Essentially you probably wonder why ToC can add IE at all (and suggest to remove this option) or request index entries to be added to the cross-reference-able types (like bookmarks). Please clarify.
(In reply to Heiko Tietze from comment #5) > > I understand the request/s as > * allow cross-reference to index entries (with the argument that it can be > added to the ToC) > Then for the user, a TOC-inserted IE is expected to behave like an "ordinary" heading. I.e. in addition of TOC appearance, the IE should be reference-able the same as "See chapter xxx p.yy" for "ordinary" heading. > I don't understand > * "It (the index entry) is assigned an outline level" (the field is not a > paragraph, the H2 "Lorem" is not the IE but you added a cross-reference > later) The Lorem ipsum paragraph (3rd para from top of file) is an index entry. I _simulated_ an Xref to it in the before-last paragraph by adding a bookmark on "See >Lorem …<", hence the gray background. There is no real Xref. It is purely illustrative to show what I'd like to do. You may suggest I could have created the bookmark on the index entry. That is precisely what I don't want to do: it would be double-work: index + bookmark both manually. > * an index entry lacks many properties of standard headings (how can you > compare the two things?) I know that are different things… > > Essentially you probably wonder why ToC can add IE at all (and suggest to > remove this option) or request index entries to be added to the > cross-reference-able types (like bookmarks). Please clarify. … but: since an "index entry" can be assigned to TOC (vs. Alphabetical Index or User "Index"), it acquires distinctive properties. 1. it can no longer be distinguished with keys 2. it somehow becomes "unique", i.e. identical entries can no longer be combined because entries are then listed in document order Considering these properties, such TOC IE become quasi-headings. Headings can be Xref'ed for page number, referenced text or chapter number. Of course, the latter won't get you an "integrated" chapter number because you can't assign the internal heading numbering style outside Tools>Heading Numbering (only a single paragraph style can be designated at any level). The main difference is such IE are not necessarily full paragraphs. IMHO this fact offers a solution to the problem of run-in headings, except for heading numbering. The main point of my "complaint" is the impossibility to cross-ref the IEs. As I mentioned above, TOC-IEs are "logically" and technically (as far as I can judge) no longer ordinary IEs. Ordinary IE are not cross-reference-able because they are not unique. The same IE may occurs at several locations (this is the main reason for alphabetical index). But TOC-IEs ARE unique with "key" index text+location, the same headings are unique with text+location. You can write a document where the same heading text is present at several locations, e.g. a document where all chapters have the same sub-chapters. This does not preclude you from Xref'ing these sub-chapters. I hope you understand my primary argument is the destination of the IE (=TOC) which makes it different from alphabetical index IE. I would say the same holds for user-index IE because these user indexes are in fact user TOCs. Just a side-remark: I have always been worried by the use of word "Index". In my native language, this word is rather meant to designate alphabetical index while TOCs and others are preferentially named "tables" (with again an ambiguity in Writer with the table feature, an area divided into cells). This illustrates the difficulty to find a non-ambiguous vocabulary.
Mike, what speaks against cross-referencing index entries? I could also follow an argument to remove this option from the ToC.
I didn't check the code, also didn't check the standard. My impression is that the reason is just "it's not implemented". I feel that the request is logical, and there shouldn't be something substantial blocking it.
(In reply to Mike Kaganski from comment #8) > "it's not implemented" So let's do.