Index: Thema und Unterthema

[xul1]

bei der Arbeit mit dem Index wird das Thema (z.B. Orte) alphabetisch in die Unterthemen (z.B. Berlin, Breslau....) eingeordnet. Das lässt sich manuell wieder richtig stellen, ist jedoch jedes Mal viel Arbeit.

Ein Programmierfehler oder mache ich was falsch?

[walt.farrell]

Perhaps I am confused, but in an Index the entries are usually supposed to be alphabetical. On the other hand, a TOC (Table of Contents) is by page number.

I have seen books in non-English languages that seem to use the term Index where we would use TOC. Is that perhaps the case for you? In that case, you should probably use a TOC rather than an Index. But if not, can you explain a bit more about what you're trying to accomplish?

[xul1]

Völlig richtig, Indexworte sind alphabetisch geordnet. Aber das "Oberthema" ist hierarchisch anders als das "Unterthema". Das Thema "Ort" hierarchisch über den Unterthema "Berlin, Breslau usw.". Wenn der Begriff Ort alphbetisch in Berlin, Breslau eingeordnet wird, ist das falsch. Und wie man am Screenshot sieht ist das Ergebnis chaotisch: Berlin, Gumbinnen und Thorn sind noch als Unterthema unter Orte gelistet, die anderen Ortnamen als Thema

[MikeTO]

Hi, I'm having difficulty understanding how you want the index to appear. Do you want it to look like this?

• Berlin
• Bleicherode
• Breslau
• Gumbinnen
• Halle
• Hauröden
• Heist
• Königsberg
• Rauschen
• Speyer
• Tannenberg
• Thorn

If this isn't it, could you please show us how you want it to appear?

[thomaso]

2 minutes ago, MikeTO said:

If this isn't it, could you please show us how you want it to appear?

You missed the parent keyword: "Orte" (Engl.: ~ locations, cities, towns, … children of 'countries'). Then "Orte" should contain most or all of these keywords, not just 3 of them. Whereas "Heimat" possibly is not meant to be part of "Orte", could be rather meant as area (Engl.: homeland).

[xul1]

6 hours ago, MikeTO said:

Hi, I'm having difficulty understanding how you want the index to appear. Do you want it to look like this?

• Berlin
• Bleicherode
• Breslau
• Gumbinnen
• Halle
• Hauröden
• Heist
• Königsberg
• Rauschen
• Speyer
• Tannenberg
• Thorn

If this isn't it, could you please show us how you want it to appear?

 

6 hours ago, MikeTO said:

 

MikeTo, vielen Dank: Genau so soll der Index aussehen. Dies alles sind die im Programm so genannten "Unterthemen", die dem Thema  "Orte" (engl. location) aber untergeordnet sind. Es gibt nämlich noch ein Unterthema "Personen" (Kant, Hitler usw.) und ein Unterthema "Sonstiges" ...

[xul1]

6 hours ago, thomaso said:

You missed the parent keyword: "Orte" (Engl.: ~ locations, cities, towns, … children of 'countries'). Then "Orte" should contain most or all of these keywords, not just 3 of them. Whereas "Heimat" possibly is not meant to be part of "Orte", could be rather meant as area (Engl.: homeland).

Ich habe "Orte" als "Thema" (engl. parent keyword?) eingerichtet und alle Namen der einzelnen Orte als Unterthema. "Heimat" gehört wahrscheinlich nicht in diese Liste, aber ich habe es erst einmal reingenommen. Dann war alles richtig: Orte und auf der Ebene darunter die einzelnen Orte. Nachdem ich die einzelnen Orte indiziert habe und eine weitere Datei indiziere, ist diese Ordnung weg: Stattdessen gibt es das Bild, das ich auf dem Screenshot geschickt habe.

[thomaso]

3 hours ago, xul1 said:

Dann war alles richtig: Orte und auf der Ebene darunter die einzelnen Orte. Nachdem ich die einzelnen Orte indiziert habe und eine weitere Datei indiziere, ist diese Ordnung weg:

Do you mean the hierarchy of existing entries used to be as wanted (all nested in "Orte") but changed for the existing keywords when new keywords got added? – Or were only the new keywords added without the parent "Orte" while your selected parent topic "Orte" got ignored by the app?

(ich schreibe ich Englisch weiter weil zur Problemlösung evtl. jemand mit V2 gebraucht wird, zB @MikeTO)

[xul1]

the hierarchy of existing entries used to be as wanted (all nested in "Orte") but changed when I applied  it to another file (1-afpub, 2-afpub...)

[walt.farrell]

18 minutes ago, xul1 said:

but changed when I applied  it to another file (1-afpub, 2-afpub...)

Can you explain a bit more about what you applied to the other file, and how you applied it?

[xul1]

I have an *.afbook and the files 01.afpub, 02.afpub to 11.afpub. 

I open 01.afpub and go to the index panel. Then I select a word and search for it by
right click in the whole file via "search in document". If I
find something, I can index the word, i.e. insert it into the index.

when I'm done, I'll have to repeat this for the next file 02.afpub. To do this, I have to open it and then when I go back to the index, the order of the list is wrong.

[walt.farrell]

3 hours ago, xul1 said:

I have an *.afbook and the files 01.afpub, 02.afpub to 11.afpub. 

I open 01.afpub and go to the index panel. Then I select a word and search for it by
right click in the whole file via "search in document". If I
find something, I can index the word, i.e. insert it into the index.

when I'm done, I'll have to repeat this for the next file 02.afpub. To do this, I have to open it and then when I go back to the index, the order of the list is wrong.

Thanks.

You said "If I find something, I can index the word, i.e. insert it into the index", but how are you doing that? Are you

• simply checking the box in the Index panel?
• Or are you couble-clicking to locate the text within the document, and then manually inserting an Index Mark in the text, e.g., by clicking the icon in the Index panel or using the keyboard shortcut (Ctrl+Alt+Shift+[ on Windows, by default).

If you just check the box in the index panel it will work fine. However, if you manually insert the Index Mark, you need to manually choose the Parent Topic title yourself, from the list you get if you click the Parent Topic pulldown. If you don't choose the Parent Topic from the list, it will be blank.

[thomaso]

1 hour ago, walt.farrell said:

If you don't choose the Parent Topic from the list, it will be blank.

However, this does not explain the lost parent topics of existing keywords which had been sorted hierarchically as expected before.

[walt.farrell]

20 minutes ago, thomaso said:

However, this does not explain the lost parent topics of existing keywords which had been sorted hierarchically as expected before.

I think it can.

Consider:

1. In chapter 1.afpub you create some index entries, with parent topics.
2. You use the Index panel to search for an existing Index term, in chapter 2.afpub.
3. It finds one, so navigate to it and you use Ctrl+Alt+Shift+[ to add an index entry, but you neglect to specify the Parent Topic.
4. You now have the earlier entry (from step 1) that has a Parent, and the new entry (from step 3) that doesn't. Same terms, just different hierarchy as you forgot to specify the parent.

Basically, at step 3, you either need to remember to choose the right Parent from the list, or you need to just check the entry in the Result list in the Index panel, instead of manually adding the entry.

[thomaso]

45 minutes ago, walt.farrell said:

4. You now have the earlier entry (from step 1) that has a Parent, and the new entry (from step 3) that doesn't.

So what? Again this does not explain the lost parent topics of existing keywords which had been sorted hierarchically as expected before: If you just create additional entries (same or different) but without parents then the existing entries must not change. Whereas the OP reports a change of existing entries.

@xul1, is this an reproducible issue that happens every time now? Possibly you can upload a screencast (video) that shows a moment of the change of an existing entry that you created as new entry in 01.afpub as child of "Orte" and that becomes hierarchically moved when an additional keyword gets added in 02.afpub?

[walt.farrell]

5 minutes ago, thomaso said:

If you just create additional entries (same or different) but without parents then the existing entries must not change. Whereas the OP reports a change of existing entries.

I'm not sure whether that's what is being reported, or not, and I don't think we will know for sure without additional screenshots, or (as you've suggested) a video, or a set of sample documents before and after.

 

[thomaso]

1 minute ago, walt.farrell said:

I'm not sure whether that's what is being reported,

Quite literally here:

8 hours ago, xul1 said:

the hierarchy of existing entries used to be as wanted (all nested in "Orte") but changed when I applied  it to another file (1-afpub, 2-afpub...)

But I agree, the debate is guessing only without being able to reproduce the issue or seeing what exactly is triggering the change.

@xul1 do the index panel entries & the index text frame appear identical in both documents after the unwanted change?

[walt.farrell]

2 minutes ago, thomaso said:

Quite literally here:

8 hours ago, xul1 said:

the hierarchy of existing entries used to be as wanted (all nested in "Orte") but changed when I applied  it to another file (1-afpub, 2-afpub...)

Good point. But if some new entries were created outside Orte, giving a mix of new outside, and old/new inside, that could also provide an explanation.

[thomaso]

19 minutes ago, walt.farrell said:

But if some new entries were created outside Orte, giving a mix of new outside, and old/new inside, that could also provide an explanation.

How? It would be like your recipe (1-4), just proofing the recipe itself. – While the OP's screenshot does not show any double entries.

The question can't be if or how the OP could have created the current index state by a wrong custom workflow (no doubt it could be). But also we can not answer what happened if its an app issue and how to avoid it unless the unwanted confusion gets reproducible by another V2 user with book feature.

Does the book feature have an option to synchronise index text frames or index panel entries? If not, could this cause such an issue or other confusion? I am curious when the confusion occurred initially, e.g. while editing the index, or later, when re-opening the .afpub. And with both .afpubs opened or just one, or which one as the currently active document?

[walt.farrell]

12 minutes ago, thomaso said:

Does the book feature have an option to synchronise index text frames or index panel entries?

The Index itself is created by the user in a Text Frame one of the .afpub chapter files.

The Index entry data is (somehow) managed by the Book feature such that the data in the Index panel includes/covers all the chapter files. But Searching from within the Index panel is restricted to the chapter that has editing focus.

When the Book is output, the Index Text Frame incorporates all the data.

[xul1]

On 7/21/2023 at 7:53 PM, walt.farrell said:

I think it can.

Consider:

1. In chapter 1.afpub you create some index entries, with parent topics.
2. You use the Index panel to search for an existing Index term, in chapter 2.afpub.
3. It finds one, so navigate to it and you use Ctrl+Alt+Shift+[ to add an index entry, but you neglect to specify the Parent Topic.
4. You now have the earlier entry (from step 1) that has a Parent, and the new entry (from step 3) that doesn't. Same terms, just different hierarchy as you forgot to specify the parent.

Basically, at step 3, you either need to remember to choose the right Parent from the list, or you need to just check the entry in the Result list in the Index panel, instead of manually adding the entry.

What I do step by step:

1. Opening afbook, opening 01.afpub

2. Index panel. I find my list of words, which I m looking for

 

3. I mark one of the words by clicking with the right mouse button, for example "Halle"

 

 

 

4. I click on Insert Marker.

I check that the word displays the index marker in the text.

 

 

 

5. I check, by displaying the finished index (although it only contains the sample word

"Halle" on page 4

6. I now open 03.afpub and the order is gone.

 

[xul1]

I am sorry, but I could only show what steps I have taken.
I do not understand the further discussion.
Unfortunately, I come to the conclusion that Affinity Publisher is not suitable for creating a book index by a regular writer.

[thomaso]

9 hours ago, xul1 said:

I do not understand the further discussion.
Unfortunately, I come to the conclusion that Affinity Publisher is not suitable for creating a book index by a regular writer.

Das "further" war wohl, um versch. Möglichkeiten zu erwägen oder auszuschließen. Ob das Problem von der Buch-Funktion ausgelöst wird, kann ich in V1 leider nicht ausprobieren.

• Wenn die Index-Palette verwirrt ist, wird dann ein Index-Udate im Text-Layout identisch fehlerhaft dargestellt?
• Sieht die Palette auch in den anderen Dateien so aus, wenn sie in einer der Dateien falsch gezeigt wird?
• Hast du den Index (also das Ergebnis im Text-Layout) nur in einer .afpub oder in jeder der Dateien erzeugt?

On 7/20/2023 at 4:43 PM, xul1 said:

ist jedoch jedes Mal viel Arbeit.

Solange der Fehler bestehen bleibt, hilft es vielleicht, ihn nicht "ständig" zu korrigieren, sondern zunächst zu ignorieren und erst nach Abschluss aller Index-Marken-Setzungen die Sortierung nur 1x zu reparieren.

Keine Lösung, nur ein Hinweis: Du kannst Einträge in der Index-Palette auswählen und mit gedrückter Maustaste alle ausgewählten an eine andere Stelle in der Hierarchie verschieben. Beim Auswählen können die üblichen Tasten benutzt werden, um einzelne oder mehrere zusammenhängende auszuwählen, oder auch, um aus einer Auswahl einzelne wieder abzuwählen (zb "Orte", wenn vorher mit Shift alle Einträge ausgewählt wurden). Beim Verschieben macht es einen Unterschied, ob du nur einen Oberbegriff oder auch seine enthaltenen Stichwörter ausgewählt hast. Das Verschieben lässt sich rückgängig machen (History-Palette / cmd-Z).

Hier sind der erste + die letzten zwei Worte ausgewählt, beim Loslassen würden sie in Africa landen:

Hier sind alle ausgewählt + dann Europa abgewählt und alle werden nach Europa verschoben. Weil auch alle Unterbegriffe gewählt sind, wird ihre Hierarchie aufgelöst und alle Stichworte sind nach dem Loslassen alphabetisch sortiert. Die oberste Ebene ("Location") bleibt dabei als oberste erhalten (obwohl sie mit ausgewählt ist).

–>