Antwort auf [ Uwe ]

Jedesmal, wenn das Inhaltsverzeichnis im UI vom Anwender aktualisiert wird, ändern sich die IDs und respektive Namen von Hyperlink, Quelle und Ziel. Egal, ob neue Einträge hinzukommen oder nicht!

Was bedeutet das für die Ermöglichung eines Zugriffs auf diese versteckten Hyperlinks?

Am ehesten wohl nur ein kurzfristiger Verwendungszweck (bis zur nächsten Aktualisierung des Inhaltsverzeichnisses), wie etwa den oben erwähnten direkten Zugriff auf den Inhalt für Quelle und Ziel.

Was für Verwendungsmöglichkeiten könnte man sich darüber hinaus noch vorstellen?

Was bedeutet die Option *mit* PDF-Lesezeichen?
Handelt es sich dabei lediglich um die *Scharfstellung* eines Hyperlinks, der unter der Haube ohnehin schon angelegt wird?

Hallo, Martin!
Ja, das sehe ich ähnlich: kurzfristiger Verwendungszweck.

Allerdings eine mögliche Anwendung:
Ein Panel mit dem Inhalt des TOC als Liste und einem Button, der das Ziel (die Seite) des ausgewählten Listeneintrags ansteuert und anzeigt.

Ob das allerdings ein starkes Argument für eine Scriptentwicklung wäre?
Hm. Die Bausteine dafür haben wir jedenfalls fast zusammen.

Bei mehreren TOCs wäre allerdings zu überlegen wie wir am geschicktesten an eine Sortierung der Hyperlinks nach Zugehörigkeit zum einzelnen TOC herankommen…

Hallo kkauer,

Zitat

Tolle Sache(n). Aber irgendwie läuft dieser Thread gerade irgendwie aus dem Ruder, oder?

100 % richtig, da habe ich auch oben schon drauf hingewiesen.

Ich wollte nur auf die Anmerkungen von Herr Fischer reagieren. Ok, vielleicht hätte ich sie so im Raum stehen lassen sollen.

Ausgangsfrage war:
Wird die Erstellung des Inhaltsverzeichnisses über Hyperlinks realisiert?

Dafür wollte ich gerne eine Bestätigung haben.

Und:
Wenn ja, was kann man damit anfangen?

Hallo Uwe,

Ja, das sehe ich ähnlich: kurzfristiger Verwendungszweck.

Klar, aber wenn die Neuerstellung eines Inhaltsverzeichnisses nach Seitenverschiebung ein so großes Problem ist, dann wäre diese Hyperlinkliste eine hervorragende Basis für eine Lösung.

Zitat

Allerdings eine mögliche Anwendung:
Ein Panel mit dem Inhalt des TOC als Liste und einem Button, der das Ziel (die Seite) des ausgewählten Listeneintrags ansteuert und anzeigt.

Das genau macht meine Lösung (zufällig) schon jetzt, allerdings ohne extra Button, sondern durch Klick auf einen Eintrag der Liste, der gleichzeitig weitere Infos über den Hyperlink freigibt.

Selbstverständlich als nicht modales Fenster (Panel) realisiert. Bei Bedarf kann man auch noch weitere Fenster öffnen.

In der neuen Version werde ich zusätzlich noch den (verkürzten) Quelltext (hier: Inhaltsverzeichniseintrag) anzeigen.

Zitat

Bei mehreren TOCs wäre allerdings zu überlegen wie wir am geschicktesten an eine Sortierung der Hyperlinks nach Zugehörigkeit zum einzelnen TOC herankommen…

Auch das sollte problemlos realisierbar sein, denn die Treeviewknoten sind sortierbar (die Kriterien erweitere ich gerade) und können gefiltert werden.

Sortierung und Filterung bauen dabei immer auf dem Ergebnis der Aktion auf, so das mehrstufiges Arbeiten möglich ist.

Hast Du so etwas gemeint?

Hallo, Werner!
Ja, das dachte ich mir schon, dass die Ziele der einzelnen Links mit Deinem Script ansteuerbar sind.

Was möglicherweise fehlt ist eine Oberkategorie, die "Inhaltsverzeichnisse" heisst und die jeweiligen Einträge entsprechend filtert.

Wie Du die Zugehörigkeit zum einzelnen Inhaltsverzeichnis hinbekommen willst, wenn mehrere TOCs vorhanden sind, darauf bin ich mal gespannt.

Antwort auf:

Wie Du die Zugehörigkeit zum einzelnen Inhaltsverzeichnis hinbekommen willst, wenn mehrere TOCs vorhanden sind, darauf bin ich mal gespannt.

Spannend auch die Sortierung der Inhaltseinträge mit mehreren Überschriften unterschiedlicher Hierarchie auf einer Seite mit mehreren Textrahmen und/oder Spalten. ;-)

Hallo Uwe,

Zitat

Was möglicherweise fehlt ist eine Oberkategorie, die "Inhaltsverzeichnisse" heisst und die jeweiligen Einträge entsprechend filtert.

Zur Zeit (in Arbeit), sieht das noch so aus, weil ich ja eher zufällig auf die Problematik gestoßen bin:

Einträge nach Typ getrennt, aber in einer Liste:

QV: -> Querverweis
HL: -> Hyperlink
IV: -> Inhaltsverzeichniseintrag

Sobald ich weiß, ob es Sinn macht, diese Einträge wirklich sichtbar zu machen, werde ich es wohl so realisieren:

Code

TV 
   Hyperlinks 
      Querverweise 
      Hyperlinks 
      Inhaltsverzeichnis-Einträge 
      ??? Stichwortverzeichnis-Einträge ??? 

zusätzlich, wie bei Quellen und Zielen, Extra-Fenster.

Das wäre alles kein allzugroßes Problem.

Zitat

Wie Du die Zugehörigkeit zum einzelnen Inhaltsverzeichnis hinbekommen willst, wenn mehrere TOCs vorhanden sind, darauf bin ich mal gespannt.

Ich würde Dir ja gerne die Spannung nehmen, aber mir fehlen als Arbeitsgrundlage Beispieldateien, und so lange ich die nicht habe, habe ich natürlich keine Idee.

Auch auf die Problematik des Inhaltsverzeichnisses bin ich erst durch eine Kundendatei gestoßen.

Hallo Herr Fischer,

Zitat

Spannend auch die Sortierung der Inhaltseinträge mit mehreren Überschriften unterschiedlicher Hierarchie auf einer Seite mit mehreren Textrahmen und/oder Spalten.

ich finde das gar nicht so spannend, nehmen Sie mein Skript, lesen Sie die Hyperlinks ein, öffnen Sie die Knoten, und schauen Sie, wie sich die Einträge unterscheiden.

Sie haben die Beantwortung dieser Frage in der Hand.

In der Regel sollte sich das Problem aber schon relativ leicht über die Gliederungssystematik lösen lassen.

think positive :-)

Hallo, Martin & Werner!

Jetzt mal "Butter zu de Fische":

Wie könnten die Kriterien aussehen, um einen bestimmten Hyperlink eindeutig einem Inhaltsverzeichnis zuordnen zu können? Eine direkte Verbindung über eine Property des Hyperlinks scheint es nicht zu geben. Oder liege ich da falsch?
(Dann hätte sich der Rest dieses Postings erledigt, und wir können von einem Scheinproblem ausgehen!)

Ich zähle mal auf, was mir dabei einfällt:

I. Die Notation des Namens in Abhängikeit zur ID
II. Das Ziel ist immer eine Seite
III. Die Quelle ist immer vom Typ "Text"

Allerdings reichen alle diese drei Kriterien meiner Meinung nach NICHT aus, um das wasserdicht zu bekommen.

Kriterium I scheint zunächst ein "hartes" zu sein, wird aber von der Tatsache getrübt, dass sich beliebige Hyperlinks auch umbenennen lassen.
Also besteht die Chance, dass ausgerechnet der Name eines "normalen" Hyperlinks vom Typ "Text" und Ziel "Seite" dessen ID-Zahl mit einem Punkt davor entspricht. Und wer behauptet, das könne in 99,99% aller Fälle ausgeschlossen werden, der hat zwar Recht, aber ihr wisst ja: "Shit happens!"

Eine Ausweichmöglichkeit zu den 3 oben genannten Kriterien und gleichzeitig die einzige Möglichkeit einzelne TOCs voneinander zu unterscheiden wäre:

0. Alle infrage kommenden Hyperlinks und deren IDs speichern.
1. TOC aktualisieren => Nun fehlen IDs und neue sind hinzugekommen.
2. Fehlende Hyperlink-IDs in Array speichern => werden anschließend noch gebraucht.
3. Die zum TOC zugehörige Story ermitteln
4. Über die Story kommen wir an die ID des ersten zugehörigen TextContainers
5. Dessen ID in eine Variable speichern => wird später noch gebraucht.

1.-5 rückgängig machen, da wir den bestehenden TOC erhalten wollen (ein Update würde nachträglich eingefügte Formatierungen und editierten Text etc. zerstören).

6. Identifizierung der Story über die in 5. ermittelte ID.
?? Analyse des Texts-Objekts dieser Story auf mögliche "normale" Hyperlinks und deren IDs, die die Kriterien I. - III. erfüllen. (Wie? Noch habe ich keine Ahnung! Hyperlinks sind ja dummerweise keine Eigenschaft von Texts-Objekten, sondern ausschließlich des Document-Objekts!)

7. Deren IDs vom in 2. gespeicherten Hyperlink-ID-Array abziehen

=> Somit wären alle zum TOC gehörigen Hyperlinks bzw. deren IDs eindeutig identifiziert.


Praktisches Problem:

Das Dokument kann mehrere TOCs enthalten, die über mehrere tocStyles abgebildet werden.
Aber: nicht alle tocStyles müssen verwendet worden sein!

Mögliche Lösung:
Update aller tocStyles über die createTOC()-Methode mit zwei Parametern und das Löschen des neuen Textrahmens, der dabei erzeugt wird, wenn der tocStyle bisher nicht benutzt wurde.

Siehe folgendes Snippet:

Code

//ASSUMPTION: All text frames in the document are unlocked! No locked layers! No hidden layers! 
 
var d=app.documents[0]; 
 
for(var n=0;n<d.tocStyles.length;n++){ 
 
    //Let's check the length of the text frames collection in the document 
    //and store its value for further use: 
    var textFramesLength = d.textFrames.length; 
     
    //NEXT: we will update a single TOC by using the createTOC() method 
    //1. argument is set to a single tocStyle 
    //2. argument is set to "true" (= just update an existing TOC) 
     
    //However: 
    //An UNUSED tocStyle will always generate a NEW text frame! 
    //An already used tocStyle will NOT generate a NEW text frame! 
     
//(What will happen, if the text frame is locked? Or hidden? Should we care for that?) 
//(Let's assume for simplicity that no text frame in the document is locked!) 
     
    //createTOC() will return an Array of Stories. 
    //Its length = 1, because we use one single tocStyle every time we loop. 
     
    //We store the Story object of the just updated (or new) TOC in a variable: 
     
    var tocStory = d.createTOC(d.tocStyles[n],true); 
 
    //We have access to the text frame of that Story Object 
    //by its textContainer: 
    var parentTextFrameOfToc = tocStory[0].textContainers[0];  
 
    //After updating (or generating) a TOC we check, if the text frames collection of the document  
    //is still the same length as before. 
     
    //If NOT, we can remove the text frame of the recently created TOC: 
    if(d.textFrames.length != textFramesLength){ 
        parentTextFrameOfToc.remove(); 
        }; 
 
    }; 

Dies alles bitte nur als Skizze betrachten.

Direktere Wege wären mir natürlich willkommen, aber solange das DOM über keinen Objekttyp "Toc" verfügt mit allen entsprechenden Methoden und Eigenschaften, ist das alles, so fürchte ich, nicht so einfach zu ermitteln.

Hallo Uwe,

mir ist das eigentlich ein wenig zu theoretisch, ich arbeite gerne mit Beispieldateien, und die sollten unbedingt aus der Praxis kommen.

Jede speziell erzeugte Musterdatei beinhaltet die Gefahr der Simplifizierung.

Zitat

Wie könnten die Kriterien aussehen, um einen bestimmten Hyperlink eindeutig einem Inhaltsverzeichnis zuordnen zu können?

Meinst Du einem Inhaltsverzeichnis, oder einem bestimmten Inhaltsverzeichnis von mehreren?

Im ersten Fall mache ich zur Zeit einfach Folgendes bis zum Beweis des Gegenteils:
1. Beginnt der Name mit einem "."
(soll vermutlich "hidden" bedeuten)
wenn ja,
-> geht der Name mit einer Integer weiter?
wenn ja (im Moment eigentlich schon hinreichend)
wenn Du's aber noch genauer prüfen willst:
erfüllen die Namen von Source und Destination die gleichen Kriterien?
wenn ja
Ist der Eintrag ein Hyperlink (hat also keine CrossReferenceSource)
wenn ja
ist Source Textsource?
wenn ja
ist Destination Pagedestination?
wenn ja -> Inhaltsverzeichnis.

Zitat

Kriterium I scheint zunächst ein "hartes" zu sein, wird aber von der Tatsache getrübt, dass sich beliebige Hyperlinks auch umbenennen lassen.

Der normale InDesign-Anwender kann solche Einträge doch wohl nicht umbennen, weil versteckt, oder?

Zitat

!@#$%^&* happens!"

Ja, ist so, InDesign stürzt von Zeit zu Zeit sogar ab ;-). Ich will natürlich besser sein, aber kein Programm ist fehlerfrei!

Ich denke solch eine Einschränkung wäre tolerabel.

Mehr wäre meines Erachtens nach ein Overkill.

Ich bin sicher, wenn das Problem wirklich auftauchen sollte, kann ich es lösen, ev. mit einem Deiner Vorschläge.

Zitat

Dies alles bitte nur als Skizze betrachten.

Direktere Wege wären mir natürlich willkommen, aber solange das DOM über keinen Objekttyp "Toc" verfügt mit allen entsprechenden Methoden und Eigenschaften, ist das alles, so fürchte ich, nicht so einfach zu ermitteln.

Liefere mir mit ein Dokument, das mit Bordmitteln (also ohne Umbennung per Skript) nicht von meinen Kriterien erkannt wird, dann schaue ich weiter.

Hallo Uwe,

hab's nur mal kurz überflogen.
Aber ich glaube, Du hast Dir selbst ein Stichwort gegeben. ;-)

Antwort auf:

Direktere Wege wären mir natürlich willkommen, aber solange das DOM über keinen Objekttyp "Toc" verfügt mit allen entsprechenden Methoden und Eigenschaften, ist das alles, so fürchte ich, nicht so einfach zu ermitteln.

Es gibt immerhin eine Eigenschaft StoryType der story mit dem möglichen Wert StoryTypes.TOC_STORY.

Ein möglicher Ausgangpunkt?

Hallo, Martin!

Danke für den Schubs mit dem StoryType StoryTypes.TOC_STORY.
Das könnte es vereinfachen…

Also abgleichen, ob die Quellen möglicher TOC-Hyperlink-Kandidaten in genau so einer Story liegen und dann danach die Gliederung nachvollziehen. So oder ähnlich…

Jedenfalls: "Food for Thought"!


@Werner – wir wissen noch nicht:
1. Ob wirklich ausschließlich diejenigen Hyperlinks, die über ein neues oder ein aktualisiertes TOC erzeugt werden, mit der Punktnotation auf Basis ihrer eigenen ID benamt werden.

Zumindest scheint es so, dass alle Hyperlinkziele vom Typ "Seite" genau nach diesem Schema benamt sind. So jedenfalls meine Erfahrung beim Experimentieren.

2. Ob nicht doch ein Anwender einen ganz "normalen" Hyperlink einen Namen gibt, der ihn vermeintlich als TOC-Hyperlink kennzeichnet.
Das ist "schnell" geschehen: einfach einen neuen Hyperlink anlegen, Ziel: Seite, Name eine Zahl mit einem Punkt vorangestellt. Wenn dann die Zahl der ID des Hyperlinks entspricht, ist's passiert!

Oder es wird ein Skript im Vorfeld benutzt, das automatisch Hyperlinks erzeugt und die Namen entsprechend einträgt. Die Idee zur Notation könnte dem Skripter ja beim Untersuchen aller möglichen Hyperlinkziele gekommen sein ;-)

Also ihr beiden: Danke für die Kommentare und:
"Back to Square 1" mit meinen Überlegungen.

Hallo Uwe,

Zitat

@Werner – wir wissen noch nicht:
1. Ob wirklich ausschließlich diejenigen Hyperlinks, die über ein neues oder ein aktualisiertes TOC erzeugt werden, mit der Punktnotation auf Basis ihrer eigenen ID benamt werden.

Du hast natürlich recht, wir wissen wirklich nicht, ob das so ist.

Aber ist es wirklich wahrscheinlich, das es anders ist?

Solche Dinge folgen in der Regel bestimmten Programmlogiken, und davon wird ein Programmierer nur im Notfall abweichen.

Die einzige zuverlässige Methode das zu Klären, wäre ein Blick in die Dokumentation von Adobe.

Also ich verwette meinen (nicht vorhandenen Hut ;-) ) dass Inhaltsverzeichnisse zumindestens in der in der von mir benutzten Version CS6 so aufgebaut werden.

Mehr habe ich noch nicht untersucht.

Aber solche Verzeichnisse werden ja laufend aktualisiert, und sind, wie früher schon festgestellt, Momentaufnahmen.

Für mich gibt es eine wirklich große Unbekannte:

Gibt es noch andere, von Indesign generierte Einträge, die diesem Schema folgen?

Das könnte dann wirklich sehr schnell zum Problem werden während ich das Problem, das jemand seine eigenen Hyperlinks genau so benennen sollte, für sehr unwahrscheinlich halte, und wenn, dann würde ich empfehlen, das zu ändern.

Wobei genauso bedeutet Hyperlink, Quelle und Ziel nach diesem Schema benennen.

Und noch etwas beschäftigt mich.

Aus Neugier habe ich tatsächlich mal einen Hyperlink erzeugt, der genau den beschriebenen Logiken entspricht, und dieser Hyperlink bleibt für den Anwender sichtbar.

Dann habe ich den generierten Eintrag und Quelle und Ziel umbenannt, - Überraschung, dieser Eintrag bleibt versteckt.

Nach Aktualisierung des Inhaltsverzeichnis war der Eintrag verschwunden.

InDesign hat also intern eine ganz eindeutige Möglichkeit die Eigenschaft Inhaltsverzeichnis zu erkennen.

Vermutlich gibt es da eine Liste mit Ids.

Aber der Hinweis von Herrn Fischer könnte noch eine zusätzliche Sicherheit geben.

In diesem Diskussionsstrang wurde festgestellt, dass Inhaltsverzeichniseinträge unter der Haube irgendwie als bzw. wie Hyperlinks funktionieren.
Daraus ergab sich die Frage, ob es irgendwie von Sinn/Nutzen wäre, wenn diese Einträge bearbeitbar zu machen. Die im Folgenden gemachten Vorschläge wurden – zu Recht – mehr oder weniger als sinnlose Beschäftigungstherapie abgeschmettert.

Vielleicht wurde die Frage falsch herum gestellt (wie bei der Geschichte mit dem Betrunkenen, der seinen Schlüssel im Schein der Straßenlaterne sucht und nicht dort, wo er ihn verloren hat):
Aus der Beobachtung, dass Inhaltsverzeichnisse mit einer bestimmten Art von Hyperlinks verbunden sind, wurde nach dem Nutzen einer Offenlegung/Editierbarkeit derselben gefragt. Andersherum könnte man auch fragen, inwiefern es nützlich/sinnvoll sein könnte, herkömmliche Hyperlinks/Querverweise zu solchen zu machen, die den Hyperlinks der Inhaltsverzeichniseinträge ähnlich sind.

Das Besondere dieser Art von Hyperlinks ist neben ihrer Verborgenheit, ihren Namen, die mit einem Punkt beginnen und die sich aus deren ID ableiten, die Tatsache, dass sie nicht permanent, sondern nur nach Aufforderung aktualisieren.

Man könnte also fragen, worin die Ursachen für die zurückhaltende Aktualisierung dieser Hyperlinks eines Inhaltsverzeichnisses liegen, um sich diese für die Einrichtung anderer, benutzerdefinierter Hyperlinks und Querverweise zu Nutzen zu machen.

Denn dass das Aktualisierungsbedürfnis herkömmlicher Querverweise spätestens bei Verweisen auf externe Ziele (außerhalb des Dokuments mit der Textquelle) eine regelrechte Plage sein kann, ist im Zusammenhang mit Diskussionen um Querverweise in InDesign immer wieder betont worden.

Erst gestern bestätigte sich mir diese Plage, als ich mit Querverweisen auf externe Ziele von nicht geöffneten Dokumenten arbeitete: Permanent versuchte InDesign im Hintergrund diese Dokumente versteckt zu öffnen, um die Ziele zu kontrollieren. Erschwerend kam hinzu, dass in diesen Dokumenten nicht installierte Schriften verwendet wurden und das FontExplorer-Plugin eifrig bei jedem Dokument auf diese fehlenden Schriften hinwies, verbunden mit einer munteren Aufforderung, diese bei Bedarf beim Entwickler von FEX zu kaufen. ;-)
Das erwies sich bei nur relativ wenigen (ca. 60) Hyperlinks auf 4 externe Dokumente als dermaßen penetrant, dass ein vernünftiges Arbeiten nicht mehr möglich war und InDesign abgeschossen und das FEX-Plugin entfernt werden musste.


Was also ist das Besondere der Querverweise eines generierten Inhaltsverzeichnisses und wie könnte was davon behilflich sein, die fortlaufenden Aktualisierungswünsche der "normalen" Querverweise zu zügeln.

An der Benamung mit dem voranstehenden Punkt allein kann's nicht liegen.
Die Verwendung der ID im Namen dürfte für die unterdrückte Aktualisierung nicht zuständig sein.
Die Hyperlinks aus den Inhaltsverzeichniseinträgen sind wie die destination selbst hidden (hidden = true). Diese Eigenschaft ist jedoch readonly und kann nicht extra zugewiesen werden.
Bei den destinations handelt es sich um HyperlinkPageDestinations (intern) bzw. HyperlinkExternalPageDestinations (extern). Das überrascht mich insofern, als dass ich eher mit einer ParagraphDestination oder HyperlinkTextDestination gerechnet hätte, bezieht sich ein Inhaltsverzeichniseintrag doch auf Absätze mit einem bestimmten Absatzformat und nicht in erster Linie auf eine Seite.

Das Ziel sind demnach nicht die Absätze/der Text selbst, sondern die Seiten, auf denen sich diese befinden. Bei der Generierung des Inhaltsverzeichnisses spielt also auch die Ermittlung des Page-Objekts eine Rolle. Wenn im Inhaltsverzeichnis nur der Text (ohne Seitenzahl) erforderlich ist, verwundert dieses Ziel, denn für diesen allein ist die Position der Seite eigentlich irrelevant.

Eventuell ist es so, dass bei der Generierung eines Inhaltsverzeichnisses unter der Haube etwas passiert, das von außen über die Benutzeroberfläche oder per Skript gar nicht nachgestellt werden kann.

Im oben erwähnten Buch mit Querverweisen auf externe Ziele sind diese als HyperlinkTextDestinations umgesetzt. Mein Plan ist, diese alternativ mal als HyperlinkExternalPageDestinations umzusetzen und zu prüfen, ob das positive Auswirkungen auf die Aktualisierungsproblematik hat. Diesen Test muss ich aber erst mal etwas hintanstellen. :-(

Guten Morgen Herr Fischer,

ich freue mich, dass Sie das Thema noch etwas weiter verfolgen, weil mir fast jeder Eintrag Anregungen für meine Arbeit gibt.

Zitat

Die im Folgenden gemachten Vorschläge wurden – zu Recht – mehr oder weniger als sinnlose Beschäftigungstherapie abgeschmettert.

Na ja, nicht alle. ;-)

Zwei der gemachten Anregungen halte ich für außerordentlich bedenkenswert:

1. Aus diesen Einträgen ein Inhaltsverzeichnis zu erstellen, bei dem bei Aktualisierungen, die bereits eingegebenen Änderungen nicht überschrieben werden.
Dies wäre ein ziemlich anspruchsvolles Projekt, auf das ich mich aber, bei ausreichendem Interesse, gesicherter Finanzierung und umfangreich verfügbaren Testmaterial, gerne stürzen würde. ;-)

2. Die Verwendung als Navigationswerkzeug.
Dieser Vorschlag gehört bereits jetzt zu den vielfältigen Möglichkeiten meines WpsHyperlinkInspector, wobei natürlich die jetzige Anzeige des Hyperlinknamens im Treeview-Knoten nicht sehr informativ ist.
Deshalb habe ich diesen Punkt bereits geändert, zukünftig wird immer der Anfang (Länge konfigurierbar) der Textquelle angezeigt.
So kann der Anwender durch Klick auf den Knoten an die entsprechende Stelle im Inhaltsverzeichnis springen, gleichzeitig öffnet sich der Knoten und mit einem weiterem Klick kann das Ziel angesprungen werden.
Ich überlege noch, ob ich ein Zusatzfeld einbaue, mit dem der Anwender einen Eintrag markieren kann (z. B. erledigt), um eine zusätzliche Selektionsmöglichkeit zu haben. Als Ergebnis hätte man ein Navigationsfenster auf ToDos.

Zitat

Man könnte also fragen, worin die Ursachen für die zurückhaltende Aktualisierung dieser Hyperlinks eines Inhaltsverzeichnisses liegen, um sich diese für die Einrichtung anderer, benutzerdefinierter Hyperlinks und Querverweise zu Nutzen zu machen.

Na ja, die Antwort haben Sie doch hier schon gegeben!
Man will offensichtlich InDesign nicht unnötig ausbremsen.

Wenn ich Sie also richtig verstehe, würden Sie sich wünschen, dass ihre Hyperlinks/Querverweise bei Bedarf in eine Art Schlummerzustand verfallen und nur auf Befehl aktualisiert werden.

So etwas ist sicherlich realisierbar, erhöht m. E. aber die Fehleranfälligkeit und verhindert die freie Austauschbarkeit von InDesigndateien.

Das von Ihnen bereits genannte Cross-References Pro löst das letzte Problem offensichtlich durch die Bereitstellung eines Reader-Moduls.

Zitat

Das Ziel sind demnach nicht die Absätze/der Text selbst, sondern die Seiten, auf denen sich diese befinden. Bei der Generierung des Inhaltsverzeichnisses spielt also auch die Ermittlung des Page-Objekts eine Rolle. Wenn im Inhaltsverzeichnis nur der Text (ohne Seitenzahl) erforderlich ist, verwundert dieses Ziel, denn für diesen allein ist die Position der Seite eigentlich irrelevant.

Hier bin ich jetzt etwas irritiert, wäre ein Inhaltsverzeichnis für eine Printausgabe ohne Seitenangabe nicht etwas sinnfrei?

Anders sieht das natürlich bei einem e-book aus.

Und da fiele mir dann gleich eine eventuell weitere Nutzungsmöglichkeit der Einträge ein, könnte es Sinn machen, neben den Seitenzielen zusätzlich automatisch Querverweise zu erzeugen?

Zitat

Mein Plan ist, diese alternativ mal als HyperlinkExternalPageDestinations umzusetzen und zu prüfen, ob das positive Auswirkungen auf die Aktualisierungsproblematik hat. Diesen Test muss ich aber erst mal etwas hintanstellen. :-(

Mein Bauchgefühl signalisiert eher Verschlimmbesserung ;-), aber wer weiß das schon.