Hallo mojo,

die Funktion nextItem() ist eine Bremse.
Versuche statt dessen den gewünschten Absatz direkt über den Index des Absatzes innerhalb des Textabschnitts anzusprechen.

z.B. über diesen Weg:

Code

var myPara = myFoundItems[i]; // betroffener Absatz 
var myParaIndex = myFoundItems[i].parentStory.insertionPoints.itemByRange( 0, myPara.index ).paragraphs.length; // zähle die Absätze vom Anfang des Textabschnitts bis zum betroffenen Absatz 
var myNextPara = myFoundItems[i].parentStory.paragraphs[myParaIndex + 1]; // Absatz nach dem betroffenen Absatz 

(ist so aus dem Kopf hingeblättert; probier's mal aus und wenn's klappt machst Du daraus am Besten eine Funktion oder einen Prototypen)

Antwort auf:

oder ist es tatsächlich so, dass Indesign in der Hinsicht schlecht programmiert wurde (wie ein Bekannter vermutete) und das Skripten bei großen Dokumenten einfach nicht gut durchführbar ist?

Dein Bekannter hat Recht:
Je größer ein Dokument, desto weniger Sinn macht ein Skript.
Bei Dokumenten mit mehr als 10 Seiten ist man gewöhnlich zu Fuß schneller als mit einem Skript. ;-)

Unsinn!
Es kommt darauf an, wie man das Skript strukturiert und auf welche Funktionen man zurückgreift bzw. wie man sich seine Funktionen aufbereitet. Die Performance kann also durchaus mit dem Organisationsgrad des Skripters zusammenhängen.

Hallo mojo,

ich denke, es ist offensichtlich, warum Dein Script immer langsamer wird....

Jedes "nextItem(myObj)" durchläuft die komplette Collection von vorne bis zu "myObj". Am Anfang ist das gesuchte Objekt noch vorne zu finden. Später wird es erst fast am Schluss gefunden......

Laufzeit von N !

Aber bei genauerer Betrachtung Deines Skriptes kommt mir da noch so einiges anderes komisch vor.
Warum durchläufst Du nicht die Collection mit i ?
Holst Dir in der for-Schleife jeden i-ten Treffer und machst dann den Vergleich zum (i + 1)-ten Treffer.

Dein Skript lässt sich bei mir auch so gar nicht ausführen. Habe Deine beiden Absatzformate angelegt und einen Textrahmen mit 50 Absätzen. Die Absätze haben abwechselnd "absform1" und "absform2".

Gruß,
Marc

P.S.: Tja, Martin war schneller..... :)

Marc,

vermutlich war das i als Zähler drin.
Doch innerhalb von den beiden Klammern [] wird daraus der Befehl für die Kursivschaltung.
Dieses Darstellungsproblem hier im Forum kann man umgehen, indem man vor das i in Klammern einen Punkt setzt: [.i] (habe zwei Punkte gesetzt, damit der eine sichtbar bleibt).

> Holst Dir in der for-Schleife jeden i-ten Treffer und machst dann den Vergleich zum (i + 1)-ten Treffer.

Das geht nicht, da der (i+1)-te Treffer unabhängig vom i-ten Treffer und sehr wahrscheinlich nicht der auf den i-ten Treffer folgende Absatz ist. Man muss schon den Bezug zum jeweiligen Treffer herstellen.

Die Alternative zu nextItem() habe ich oben gezeigt.
Weißt Du noch was Schnelleres?

P.S.: Tja, Martin war schneller..... :)

Danke für den Hinweis. Habe nicht so auf die korrekte Darstellug geachtet....


Vielen Dank euch beiden für die fixen Antworten! Die Lösung habt ihr ja beide gebracht, insofern danke Martin, und Marc: NextItem zeigt doch nicht auf den i+1ten Treffer, sondern auf das Objekt (besser den Absatz) nach dem jeweiligen Treffer und setzt dessen "abstand vor" auf 0. Oder nicht? Wenn man zum nächsten gefundenen Item verweisen würde würd das ja in der tat keinen Sinn ergeben. Das Skript läuft bei mir auf CS3 problemlos. ...!?

Antwort auf [ Martin Fischer ]

vermutlich war das i als Zähler drin.
Doch innerhalb von den beiden Klammern [] wird daraus der Befehl für die Kursivschaltung.

Ohh.... jetzt wo Du's sagst.... Und ich dachte schon... "FoundItems hat doch keine Paragraphs!?!?!?"
Ok, demnächst denke ich mir einfach ein [i] dazu.... :)

Antwort auf [ Martin Fischer ]

Weißt Du noch was Schnelleres?

Spontan nicht.... Klingt annehmbar.

Gruß,
Marc

Habe Deinen Skriptvorschlag mal getestet... :)
Es stimmt alles, ausser dem Sonderfall, wenn der gefundene Absatz der erste Absatz ist, also den Index 0 hat, da itemByRange( 0,0).paragraphs.length eine 1 zurückliefert. (warum auch immer!)
Wenn man dafür eine Ausnahmebehandlung macht, rennt das Skript wie verrückt... :)

*R-E-S-P-E-K-T*

Code

if (myPara.index == 0) { 
  myParaIndex = 0; 
} else { 
  myParaIndex = myPara.parentStory.insertionPoints.itemByRange( 0, myPara.index ).paragraphs.length;  
} 

Gruß,
Marc

Hallo Marc,

gut beobachtet.
Da scheint auf den ersten Blick (ohne Nachdenken) ein Bruch in der Logik zu sein.

Allerdings könnte sich das klären, wenn man nochmal genauer hinschaut, was myPara.index eigentlich ist. Es handelt sich dabei um den Index des ersten Einfügepunkts eines Absatzes.
Beim ersten Absatz ist dieser 0.
Du hast also einem itemByRange(0,0).
Die Zahl der darin enthalten Absätze ist 1 (und nicht 0 - Du kannst diesem Rangeobjekt nämlich durchaus Absatzattribute zuweisen).

Nimmst Du den zweiten Absatz als Referenz, dann ist der erste Einfügepunkt ganz am Anfang des zweiten Absatzes; der zweite Absatz also noch nicht drin angebrochen/enthalten. Deswegen ist auch hier die Zahl der vorhergehenden Absätze 1!

Du kannst das Problem, das leicht in eine philosophische Diskussion münden könnte, umgehen, indem Du nicht den ersten Einfügepunkt eines Absatzes, sondern den zweiten als Referenz nimmst:

Code

myParaIndex = myPara.parentStory.insertionPoints.itemByRange( 0, myPara.index +1 ).paragraphs.length; 

Allerdings musst Du dann bei der Adressierung des nachfolgenden Absatzes wieder berücksichtigen, dass JavaScript bei 0 und nicht bei 1 anfängt zu zählen. ;-)

Antwort auf [ Martin Fischer ]

Du kannst das Problem, das leicht in eine philosophische Diskussion münden könnte, umgehen, indem Du nicht den ersten Einfügepunkt eines Absatzes, sondern den zweiten als Referenz nimmst:
[..]
Allerdings musst Du dann bei der Adressierung des nachfolgenden Absatzes wieder berücksichtigen, dass JavaScript bei 0 und nicht bei 1 anfängt zu zählen.

... oder wie beschrieben eine Fallunterscheidung für myPara.index == 0 machen. Dann muss man auch nachher nichts mehr berücksichtigen.

Gruß,
Marc Sidon

Marc,

Du hast natürlich recht.
Technisch gesehen.

Aber so gesehen funktioniert ja auch nextItem().
Nicht alles, was funktioniert, ist auch gut. ;-)
Das hat der OP in seinem ersten Beitrag deutlich zum Ausdruck gebracht.

Deine Lösung reizt (wie oben geschrieben) zu einer überflüssigen philosophischen Diskussion, weil man einen Bruch entdeckt zu haben meint.

Deswegen habe ich einen Weg zur Umgehung des vermeidbaren Widerspruchs aufgezeigt: Nimm den referenzierten Absatz in die Zählung mit hinein. Dann braucht man nicht mehr lange hin und her zu unterscheiden und weiter zu grübeln.

Außerdem spart man einige Tastenklicks (weil nur '+1' hinzugefügt werden muss und nicht 'if das ... else das ..').
Und Du bist doch sicherlich auch darum bemüht, die Tastatur möglichst wenig abzunutzen und und Finger zu schonen. ;-)

Antwort auf [ Martin Fischer ]

Aber so gesehen funktioniert ja auch nextItem().

Du willst doch wohl eine Fallunterscheidung nicht mit dem suboptimalen Algorithmus von nextItem vergleichen.

Antwort auf [ Martin Fischer ]

Deine Lösung reizt (wie oben geschrieben) zu einer überflüssigen philosophischen Diskussion, weil man einen Bruch entdeckt zu haben meint.

Deswegen habe ich einen Weg zur Umgehung des vermeidbaren Widerspruchs aufgezeigt: Nimm den referenzierten Absatz in die Zählung mit hinein. Dann braucht man nicht mehr lange hin und her zu unterscheiden und weiter zu grübeln.

DAS ist jetzt eher das, was zu philosopischen Diskussionen führen kann! Wenn DU lieber +1-1 rechnest, als den einzigen Fall, der mit Deinem ansonsten korrekten Algorithmus "anders" funktioniert, kannst Du das ja gerne machen.
ICH hingegen bevorzuge eine Ausnahmebehandlung zu Beginn einer Routine, weil ich dann mittendrin nicht immer +1-1 rechnen muss.
So hat halt jeder seine Vorlieben bezüglich der Programmierung.

Antwort auf [ Martin Fischer ]

Außerdem spart man einige Tastenklicks (weil nur '+1' hinzugefügt werden muss und nicht 'if das ... else das ..').
Und Du bist doch sicherlich auch darum bemüht, die Tastatur möglichst wenig abzunutzen und und Finger zu schonen. ;-)

Naja, da scheiden sich eben die Geister. Der Eine spart gerne Klicks, der Andere hat's lieber gut lesbar.....

Aber ich wollte da jetzt ebenfalls keine riesen Diskussion entflammen. Ich hatte lediglich den "Sonderfall 0" beschrieben und wollte Deine Lösung nur ergänzen.

Wenn wir jetzt jedes Mal die 100 gangbaren Wege ausdiskutieren, dann sollte ich mir vielleicht ein paar Monate Urlaub nehmen. Denn das könnte länger dauern.... :)

Gruß,
Marc

Si tacuisses, philosophus mansisses!
Quod errat demonstrandum.

Felix, qui potuit rerum cognoscere causas! ;-)

Altum silentium.

Antwort auf [ Martin Fischer ]

Si tacuisses, philosophus mansisses!

Ich will ja auch keiner sein!
Ich bin Informatiker!