Hallo Hans-Jürgen,

> InDihyph ist jetzt für CS5 verfügbar.

Was für eine schöne Nachricht.
Das ist schon mal gut zu wissen.

Aber ich ziehe mich erst mal für ne Weile von CS5 zurück.

Im Moment habe ich große Probleme beim Downgrade der Dateien von CS5 auf CS4.
Zunächst sieht zwar alles ganz gut aus. Bis zu dem Moment, wo einzelnen Layoutseiten andere Musterseiten mit Objekten zugewiesen werden. Wenn auf den Musterseiten nichts drauf ist, dann ist's noch ok. Aber wehe, es sind die Marker für die automatische Seitenzahlen drauf, dann stürzt CS4 gnadenlos ab. An die Musterseiten mit Textvariablen für Kolumnentitel habe ich mich noch nicht recht rangetraut.

Ich versuche jetzt, die Dateien in CS4 neu aufzubauen, nach und nach Formate und Musterseiten und endlich die Inhalte aus den IDML-Dateien von CS5 herüber zu hieven. Schließlich stecken 3 Tage Arbeit in den Daten.

Nein, es ist nicht mehr daran zu denken, diese Dateien in CS5 weiterzubearbeiten. Ständig leert es mir einen anderen Textrahmen und verschiebt Text hinten raus in den Übersatz.

Aber ich werde gelegentlich mit einem kleineren Projekt wieder einen Versuch in CS5 wagen. Möglicherweise liegt's ja auch an meinen Dateien, die's irgendwann Mal zerschossen hat. Es fühlt sich an, als wate man in Morast: Kaum ist der eine Fuß raus, versinkt der andere wieder.

Gut zu wissen, dass InDihyph bereit steht.
Danke für diese Nachricht.

Viele Grüße
Martin

Die Dokumente sind über IDML in InDesign CS4 angekommen und dort weiterbearbeitet worden. Bislang (nach mehreren Stunden Arbeit) ist mir der oben beschriebene Fehler in CS4 nicht einmal untergekommen – in CS5 waren am Ende stets einer oder mehrere Textrahmen im Wechsel leer, so dass kein zusammenhängender Ausdruck des Dokuments gemacht werden konnte.

Einzig die Titelei mit römischer Paginierung (Dokument mit kurzen Texten ohne Fußnoten, das auf der Basis des Hauptdokuments erstellt worden war) bereite(e) neue Schwierigkeiten, die nicht in einem Zusammenhang mit dem oben beschriebenen Problem stehen und sich vermutlich auf einen Defekt des Dokuments zurückführen lassen.

Ein Bugreport mit Hinweis auf diesen Thread wurde an Adobe übermittelt.

Viele Grüße
Martin

Hier habe ich auch noch was im Adobe Forum gefunden, hat vielleicht schon der ein oder andere von euch entdeckt:
http://forums.adobe.com/message/2983182

Hallo Otoya,

danke für den Link.
Wie wohltuend es manchmal sein kann, sich mit einem Problem nicht allein zu wissen.

Adobe ist das Problem (offiziell) noch nicht bekannt:
InDesign CS5 – Bekannte Probleme (Letzte Aktualisierung: 29.04.2010!)

Viele Grüße
Martin

Hallo Martin,

Zitat

Adobe ist das Problem (offiziell) noch nicht bekannt:
InDesign CS5 – Bekannte Probleme (Letzte Aktualisierung: 29.04.2010!)

Wenn man sich die Liste anschaut, dann ist noch viel für das nächste 7.0.3 Update zu machen!

Das 7.0.2 Update welches seit Gestern raus ist hat zwar einige wichtige jedoch auch nur wenige Bugfixes:
http://kb2.adobe.com/...in_Resolved%20issues
Beste Grüße
Yves

---

yves-apel.eu

Hallo,

ich wollte fragen, ob sich wegen dem "leere Seiten Problem" schon etwas ergeben hat?
Für mich ist auf jeden Fall immernoch CS4 "angesagt", dennoch würde ich gerne umsteigen.

Hallo Otoya,

> ich wollte fragen, ob sich wegen dem "leere Seiten Problem"
> schon etwas ergeben hat?

Da es seit 7.02 noch kein neues Release dürfte sich an der Situation inzwischen nichts verändert haben (Freiwillige vor!).


Außerdem bin ich skeptisch hinsichtlich einer baldigen Lösung.

Der Fehler, der gefühlt mit der Fußnotenfunktion zusammenhängt, hält sich seit Erscheinen von InDesign CS2 (mit Einführung der Fußnotenfunktion), also inzwischen über 4 Versionen hinweg. In allen Versionen nach CS2 bis einschließlich CS5 hat sich an der Fußnotenfunktion nicht das Geringste geändert. Auch CS5 arbeitet noch mit der Fußnotenverwaltung 1.0!

Wie ist da zu erwarten, dass ein Fehler, der u.U. mit der Fußnotenfunktion zusammenhängt und nun in CS5 gehäuft auftritt, plötzlich von einem .0x Update auf das andere verschwindet?

Bei meiner Arbeit in InDesign CS4 vermisse ich nichts, was mir CS5 bieten könnte, um mich auf dieses erhöhte Risiko mit den leeren Textrahmen einzulassen.
Schade um die ungenutzte Möglichkeit, Text über mehrere Spalten laufen zu lassen. :-(

Viele Grüße
Martin

Hallo Martin,

ich glaube, dass das Problem nicht direkt mit der Fußnotenfunktion zusammenhängt.
Bei uns tritt das Problem auch in Fällen mit mehrseitigen Tabellen auf (ohne Fussnoten im Dokument). Eine Tabelle ist ja einfach gesehen auch ein Zeichen, das entsprechend hoch ist und den nachfolgenden Text nach hinten schiebt.
Also immer wenn irgendwie Text von Indesign automatisch verdrängt werden soll z.B. bei Fußnoten oder großen Tabellen dann tritt bei uns der Fehler auf.
Aber ich geb dir Recht, warum sollte ausgerechnet jetzt in der Version CS5 der uralte Fehler behoben werden?
Vielleicht wird er behoben weil er jetzt so massiv auftritt?
Wir werden sehen.

Gruss

Flo

Hallo Florian,

ich habe die Chronologie der Leistungsmerkmale von InDesign nicht mehr vor Augen.

Die Tabellen gab es schon vor den Fußnoten, oder?
Und ab wann waren Objekte verankerbar?
Gibt es irgendwo eine Tabelle, wo man den Zuwachs an Leistungsmerkmalen über die einzelnen Versionen hinweg ablesen kann?

Ich meinte nicht, dass das Problem nur in Verbindung mit Fußnoten auftaucht.
Vielmehr ist es mir aufgefallen, dass es seit der Implementierung der Fußnotenfunktion in InDesign auftaucht. Egal ob jetzt jemand davon Gebrauch macht oder nicht.

Dass das Problem auch bei Texten ohne Fußnoten auftaucht, haben andere schon bestätigt. Aber die Problematik als solche gab es vor CS2 nach meinen Beobachtungen noch nicht.

Freilich heißt das immer noch nicht zwingend, dass dieses Problem unmittelbar mit dem Einbau der Fußnotenfunktion zusammenhängt. Aber die Funktion als solche scheint mir ein fetter Brocken zu sein, der Adobe schwer auf dem Magen liegt, zeigen sich die Planer/Programmierer doch sehr verhalten, daran auch nur einen Deut zu ändern.
Im Zusammenhang mit spaltenübergreifendem Text oder in Spalten gesplitteten Absätzen wird das Gewicht der 'Altlast' der Art und Weise der Implementierung der Fußnoten nochmal deutlich: Erster Blick auf InDesign CS5.
Aber immerhin ist sie schon mal drin und es gibt keinen Schritt zurück mehr. ;:-)

Viele Grüße
Martin

Hallo Martin,

du hast natürlich recht, es haben sich keine wirklich essentiellen Änderungen in der CS5 getan, der Aufruf des Druckmenüs geht am Mac jedoch jetzt so von statten, wie es sein sollte: Es erscheint so schnell, dass man sich zwischendurch KEINEN Kaffee/Tee mehr machen kann (oder muss?) :-)

Insgesamt fühlen sich manche Dinge auch "snappier" an, aber das kann auch täuschen. Dass der doc/docx Import in CS5 noch nicht angefasst wurde ist für mich – direkt nach dem Fußnoten-Problem – die nächste haarsträubende Sache. Es gehen immernoch Fußnoten verloren oder werden verwürfelt, des Weiteren stürzt InDesign bei bestimmten docx Dateien einfach ab (auch dazu gibt es einen hübschen Artikel auf betalogue.com, falls noch nicht erwähnt).

Code

kurz einmisch 

Antwort auf [ Otoya Shimasaki ]

Es kommt anscheinend auf den Font an. Verschiedene Garamond Typen lassen die Seiten so gut wie immer "blinken" (ich nenne das jetzt mal so). Wenn ich dem gesamten Text z.B. die Arial zuweise, dann "blinkt" nichts mehr.

Auch ich kenne das Phänomen, übrigens auch aus XPress-Umgebungen: und es hatte am Ende in diesen Fällen immer mit Font-Konflikten zu tun.
Grüße, Jochen

Antwort auf [ Otoya Shimasaki ]

Es kommt anscheinend auf den Font an. Verschiedene Garamond Typen lassen die Seiten so gut wie immer "blinken" (ich nenne das jetzt mal so). Wenn ich dem gesamten Text z.B. die Arial zuweise, dann "blinkt" nichts mehr.

Zitat

Auch ich kenne das Phänomen, übrigens auch aus XPress-Umgebungen: und es hatte am Ende in diesen Fällen immer mit Font-Konflikten zu tun.

Mhm, das ist natürlich ein berechtigter Einwurf, dem steht jedoch entgegen, dass das Problem seit CS 2 mit der Fußnotenverwaltung immanent ist. Natürlich bin ich auch den Fonts nachgegangen und habe dementsprechend darauf geachtet, alle Font Konflikte zu bereinigen.

Hallo Herr Fischer,

eben ist das Bugfix 7.0.3 erschienen.
Leider finde ich auf die schnelle gerade kein Dokument mit dem Fehler.
Haben Sie vielleicht gerade eins zur Hand um den Fehler mit dem neuen Bugfix zu testen?

Gruss

Flo

> Haben Sie vielleicht gerade eins zur Hand um den Fehler
> mit dem neuen Bugfix zu testen?

Ich hab's den halben Morgen versucht.
Mit einem neuen Manuskript.

Aber verschiedene Versuche, ein Dokument in CS5 (7.0.3) einzurichten und dort weiterzubearbeiten, sind fehlgeschlagen (Import von Word-Daten liefert zuhauf rosa Kästchen statt Fußnotenverweisen trotz entsprechender Vorkehrungen – Import in CS3 liefert tadellose Daten; beim Öffnen einer aus CS3 nach CS4 konvertierten Datei stürzt CS5 sofort ab; IDML lässt sich öffnen, aber nicht mehr sichern -> CS5 hängt sich auf).

Voreinstellungen zurückzusetzen hat nichts geholfen.

Ich habe die Nase für heute voll und versuche in CS4 die verlorene Zeit wieder wettzumachen.

Von mir ist deshalb in absehbarer Zeit kein Bericht hinsichtlich Erfahrungen bezüglich des hier diskutierten Problems mit InDesign 7.0.3 zu erwarten.

edit:
Nach Fertigstellung dieses Berichts in einer frustrierten Laune stelle ich fest, dass InDesign CS5 die aus IDML konvertierte Datei letztendlich nach minutenlanger Arbeit doch noch sichern konnte und ich schöpfe Hoffnung.
Also nehme ich die letzte Ankündigung zurück und gebe InDesign CS5 während der nächsten Stunde noch eine Chance.

Viele Grüße
Martin

Hallo Florian,

das Problem taucht auch in InDesign 7.0.3 auf.

Während der letzten Stunde habe ich ca. 7 Textrahmen, die sich während leichten Umbruchveränderungen (Überschriften ausgezeichnet, Formate mit anderer Sprache zugewiesen) ergeben haben, nachbearbeitet, um sie wieder zu füllen.

Im aktuellen Dokument arbeite ich nicht mit einem Garamond-Font.
Damit lässt sich der Verdacht, dass eine Garamond ein möglicher Auslöser darstellt, zumindest abschwächen.

Einen Fontkonflikt möchte ich ausschließen.
Die Fontcaches habe ich gestern erneuert.
Und den verwendeten Font habe ich unmittelbar vor dem Anlegen dieses Dokuments gezielt aktiviert.

Viele Grüße
Martin

Hallo Herr Fischer,

da fällt mir wirklich nur noch eins ein: Schei**!
Wir wollten ja im Dezember alle Maschinen auf CS5 umstellen, aber diese Probleme sind jetzt echt ein Hindernis.
Mich würde jetzt wirklich nur noch interessieren, ob Adobe das Problem im Fokus hat, oder ob das "Warten auf Godot" ist?
Bei diesen gravierenden Fehlern müsste doch ein riesen Aufschrei durch die InDesign-Benutzerschar gehen???

Gruss

Flo

Antwort auf:

Bei diesen gravierenden Fehlern müsste doch ein riesen Aufschrei durch die InDesign-Benutzerschar gehen???

Ja, das Ausbleiben desselben verwundert mich auch etwas.
Wären nicht Deine und die entsprechenden Meldungen von Uwe Laubender, dann würde ich anfangen, an meiner Installation und Bedienung zu zweifeln.

Es muss einen Trick geben, der es den meisten InDesign CS5-Anwendern erlaubt, ohne diese Probleme produktiv arbeiten zu können.

Ich stehe schon wieder kurz vor dem Rückzug nach CS4.
Aber ich hoffe noch, irgendeine entscheidende Entdeckung zu machen.

Viele Grüße
Martin

Aus Sicht von Adobe ist das Problem unbekannt: InDesign CS5 known issues and bugs

Viele Grüße
Martin

Ich kenne das beschriebene Problem nur von CS2 in Zusammenhang mit Fußnoten...
Es wundert mich, dass es bei manchen Anwendern auch in CS3 bzw. CS4 das Problem mit den leeren Seiten gibt. In CS3 bin ich noch nie auf das Problem gestoßen.

Gruß, Peter

Hallo Peter,

> In CS3 bin ich noch nie auf das Problem gestoßen.

In CS3 und CS4 taucht das Problem sehr selten auf.
Und wenn, dann unmittelbar vor der Erstellung der Druckdaten - frei nach den Murphyschen Regeln

Zitat

»Die Wahrscheinlichkeit, dass ein bestimmtes Ereignis eintritt, ist umgekehrt proportional zu seiner Erwünschtheit.«

oder

Zitat

»Wenn etwas nicht schiefgegangen zu sein scheint, dann wurde der Fehler lediglich noch nicht entdeckt, wodurch alles nur noch schlimmer wird.«

;-)

In CS5 tritt das Problem bei längeren Texten im Zusammenhang mit Umbruchverschiebungen aufgrund neuer Formatierung mit einer gewissen Regelmäßigkeit auf.

Viele Grüße
Martin

Heute habe ich beim Umbruch von ca. 200 Seiten etwas konzentrierter auf den Kontext des Fehlers geachtet.

Er scheint von der Sprache und vom verwendeten Silbentrennmodul unabhängig aufzutreten (in meinem Dokument: Deutsch und Lateinisch: InDihyph; Französisch: Proximity). Auch durch das Ausschalten der Silbentrennung ließ sich der Fehler an Stellen, wo er reproduzierbar war, nicht unterdrücken.


Eine Sache ist mir jedoch ins Auge gestochen: dort, wo der Fehler passiert ist, stand stets ein Fußnotenverweis in der ersten Zeile (des Textrahmens).

Wurde eine Textpassage im Absatz, der in den nächsten Rahmen überlief mit einem (anderen) Zeichenformat ausgezeichnet, löste sich der Fehler damit auf (der Text sprang zurück in den Textrahmen, wo er stehen sollte). Eine erneute Zuweisung (z.B. auch desselben Formats) ließ den Text im Textrahmen wieder in den nächsten verknüpften Textrahmen springen. Und so weiter. Hin und her. Beliebig reproduzierbar. Stundenlang.

So hartnäckig (und häufig) kenne ich das Problem und die Reproduzierbarkeit des Problems nicht aus früheren Versionen von InDesign.


Allerdings führt ein Fußnotenverweis in der ersten Zeile eines Textrahmens nicht zwingend zu diesem Fehlverhalten: Es gibt an mehreren Stellen Fußnotenverweise in der ersten Zeile eines Textrahmens, ohne dass sich dort der Fehler durch Zuweisung anderer Formate provozieren ließe.


Mein Schluss (für heute): ein Fußnotenverweis in der ersten Textzeile eines Textrahmens scheint das beschriebene Fehlverhalten in InDesign zu begünstigen.

(Es gibt allerdings auch Anwender, die dieses Phänomen bei Text ohne Fußnoten beobachten konnten.)

Darüberhinaus sind mir bis jetzt keine weiteren gemeinsame Besonderheiten in der Umgebung des Fehlers aufgefallen.

Viele Grüße
Martin

Nun konnte ich noch etwas Interessantes herausfinden:

Dem Textrahmen, wo der Fußnotenverweis in der ersten Zeile den Fehler zu begünstigen scheint, geht ein Textrahmen voraus, der theoretisch mit einer weiteren Textzeile gefüllt werden könnte, wenn in der Zeile, die noch Platz finden könnte, kein Fußnotenverweis wäre. Zum besseren Verständnis im Anhang ein Bildschirmfoto.

Links ein Textrahmen mit einer Lücke zwischen Text und Fußnotenbereich, wo zwei normale Textzeilen noch unterkommen könnten.
Rechts oben die Zeile mit einem Fußnotenverweis, die mit diesem Fußnotenverweis (und den ersten beiden Fußnotenzeilen) nicht mehr in den vorherigen Textrahmen passen.

Eine Formatänderung (z.B. Kursivzuweisung) führt zu einem Hin und Her: Leeren des Textrahmens, beim nächsten Mal wieder füllen, usw.

Nun habe ich testweise dafür gesorgt, dass von der vorherigenSeite zwei Zeilen oben auf die im Bildschirmfoto sichtbare linke Seite umbrechen. Damit ist auf der linken Seite kein überflüssiger Leerraum mehr zwischen Text- und Fußnotenbereich. Die erste Zeile auf der rechten Seite fände dort also keinen Platz mehr, selbst wenn kein Fußnotenverweis darin vorhanden wäre.
Und siehe da: der Fehler lässt sich nicht mehr reproduzieren!

Kommando zurück.
Wieder Schaffung von Leerraum für eine Textzeile, der wegen dem Fußnotenverweis und den ersten beiden Zeilen der verbundenen Fußnote nicht genutzt werden kann: der Fehler lässt sich wieder reproduzieren!

Zum selben Ergebnis komme ich, wenn ich in der betroffenen Fußnote einen Schusterjungen zulasse. Dann kommt die erste Textzeile von der rechten Seite zusammen mit der ersten Fußnotenzeile rüber auf die linke Seite und ich kann formatieren wie ich will: der Fehler lässt sich nicht wieder reproduzieren!


Diesen möglichen Zusammenhang werde ich nun auch an anderen Stellen etwas intensiver prüfen.

Viele Grüße
Martin

Nun bin ich fasziniert:

Dieser Zusammenhang lässt sich an zehn anderen Stellen in dieser Form nachvollziehen.

Dort, wo eine Fußnote verhindert, dass ein Textrahmen optimal mit Zeilen gefüllt wird, dort tritt das labile Verhalten auf: der darauf folgende verknüpfte Textrahmen lässt sich durch eine Änderung der Formatierung im überlaufenden Textabsatz abwechselnd leeren und wieder befüllen.

Kann das jemand bestätigen oder durch ein Beispiel widerlegen?

Viele Grüße
Martin

Im Folgenden eine Anleitung zur Provakation des Fehlers.


1. Erstelle zwei verknüpfte Textrahmen und fülle diese mit Text.

2. Füge im Text von beiden Textrahmen jeweils eine Fußnote ein; für die Versuchsanordnung ist es günstig wenn diese vertikal etwa in der Mitte der Textrahmen platziert werden. (Rahmen_leeren_1.png).

3. Füge nun irgendwo in der letzten Zeile des ersten Textrahmens eine weitere Fußnote mit ein paar Zeilen Text hinzu, so dass diese Zeile von InDesign wegen dieser Fußnote in den nächsten Rahmen umbrochen werden muss – jedoch ohne diese Fußnote am Ende des ersten Rahmens stehen bleiben könnte. Die Umbrucheinstellung 'Zeilen nicht trennen – Am Anfang/Ende des Absatzes' mit je zwei Zeilen hilft die Provokation etwas zu vereinfachen (Zwang des Zusammenhalts von Zeilen), ist aber nicht dringend nötig (Rahmen_leeren_2.png).

4. Wähle Text im Absatz, der vom ersten Textrahmen zum zweiten umbricht aus (Rahmen_leeren_3.png).

5. Weise diesem Text ein beliebiges Zeichenformat zu (kann auch ohne abweichende Formatdefinitionen sein). Nun sollte der Text im zweiten Textrahmen verschwunden sein (Rahmen_leeren_4.png).

6. Weise der Auswahl ein anderes Zeichenformat oder das Zeichenformat [Ohne] zu. Nun sollte der Text im zweiten Textrahmen wieder erscheinen.



Lässt sich dieses Verhalten so auch auf anderen Arbeitsplätzen als meinem nachstellen?

Viele Grüße
Martin

Hallo Martin,

ich habe es gerade mal in CS3 und CS4 probiert. Da kommt das Phänomen bei mir nicht vor. Ich werde es aber noch heute Abend in CS5 prüfen und ggf. wie der andere Beitrag als Videobeweis aufzeichnen und an Adobe und Indesignsecrets schicken.
Beste Grüße
Yves

---

yves-apel.eu

Hallo Yves,

in CS3 und CS4 habe ich bislang noch keinen Weg gefunden, das Verhalten zu provozieren bzw. reproduzieren. Aber in InDesign CS5 kann ich mir ein Spiel daraus machen.

Viele Grüße
Martin

Hallo, Martin,

du hast die Vorgehensweise eindeutig genug beschrieben ;-): ich kann das Verhalten so unter CS5 (Mac) nachstellen.
Das weiter oben irgendwo mal erwähnte "Sofort alles Textabschnitte neu umbrechen" behebt den Fehler auch - bleibt aber natürlich dennoch mühsam ...

Grüße, Martin
--
Martin Heise
http://www.martinheise.de

Hallo Yves,

Antwort auf:

ich habe es gerade mal in CS3 und CS4 probiert. Da kommt das Phänomen bei mir nicht vor

Wie es der Zufall will ...

Gerade ist mir so eine 'leere Seite' bei Korrekturen in einem InDesign CS4-Dokument untergekommen: Beispiel eines Fehlers in InDesign CS4.

Interessant ist vielleicht, dass auch hier ein Fußnotenverweis in der ersten übergeschwappten Zeile steckt (links unten). Allerdings wäre im Textrahmen auf der Seite links oben kein Raum mehr für diese Zeile so dass sie auch dann nicht dort reinrutschen könnte, wenn sie denn keinen Fußnotenverweis hätte.

Auch hier sorgt die Zuweisung eines ZF einmalig dafür, dass der Text wieder zurückschnappt: danach.

Allerdings sorgt die erneute Zuweisung dieses oder eines anderen ZF anders als in CS5 nicht für die Wiederholung des Fehlers. Es bleibt nun alles korrekt.

Viele Grüße
Martin

Hallo Martin,

Antwort auf:

du hast die Vorgehensweise eindeutig genug beschrieben ;-): ich kann das Verhalten so unter CS5 (Mac) nachstellen.

Für diese Bestätigung bin ich Dir gerade sehr dankbar.
Es ist also auch andernorts nach dem Plan oben so nachzustellen.

Aber wenn dem so ist, wie kommt es dann, dass es keinen großen Aufschrei gibt und sich kaum eine Handvoll Leute an diesem Fehlverhalten stört? Arbeiten so wenige InDesign CS5-Anwender mit umfangreicheren Dokumenten mit Fußnoten?

Viele Grüße
Martin

Hallo Martin,

Antwort auf:

Aber wenn dem so ist, wie kommt es dann, dass es keinen großen Aufschrei gibt und sich kaum eine Handvoll Leute an diesem Fehlverhalten stört? Arbeiten so wenige InDesign CS5-Anwender mit umfangreicheren Dokumenten mit Fußnoten?

Ich verfolge euren Thread nun schon seit geraumer Zeit. Ich habe im Leben noch nie mit Fußnoten gearbeitet und auch Null Ahnung davon. Muss ich mich jetzt outen?

Spaß beiseite, "lange Texte" gehen bei mir über maximal vier bis fünf Seiten. Und selbst das kommt bei mir höchstens zwei Mal im Jahr vor. Alles andere ist bei meinen Jobs deutlich kürzer.

Auch wenn es euch kaum helfen wird, es ist schon traurig, dass InDesign, dessen "Long Document Features" ja von Adobe gerne hervorgehoben werden, mit solchen Dingen auch in seiner siebten Auflage noch (oder gerade erst?) Probleme hat…

Just my 2 Piasters…

---
Viele Grüße,
Ralf
---
iMac i7 (18,3) 4,2 GHz, 32 GB 10.15.7 Catalina | MacBook Pro 15" (8,2) 2,0 GHz, 16 GB, 10.13.6 High Sierra | Mac Mini (6,1) als Server 2,5 GHz, 8 GB, 10.13.6 High Sierra | CC 2021 (ID 16.3.2)

Hallo Martin,

Zitat

Für diese Bestätigung bin ich Dir gerade sehr dankbar.
Es ist also auch andernorts nach dem Plan oben so nachzustellen.

Leider anscheinend nicht bei mir. So gern ich möchte, ich bekomme diesen Fehler nicht nachgestellt. Auch jetzt in CS5 nicht.

Es kann doch nichts damit zu tun haben dass der Screenreflow bei mir auf "Immediate" steht oder ich aus Prinzip und ausschließlich nur mit dem Single-Line Composer arbeite?

Wenn du willst, schick mir mal deine Testdatei welche du für die Beschreibung benutzt hast, so dass ich nur noch das Zeichenformat zuweisen muss. Dies sollte ja dann ein sicherer Garant für Erfolg für die Fehlerreproduktion sein.

Ich kann allerdings behaupten dass bei za 35 Computern auf denen hauptsächlich CS3 aber auch vereinzelt CS4 installiert ist, und wo regelmässig mit langen Dokumenten gearbeitet wird, dieser Fehler noch nicht aufgetaucht ist. Und da hat schon bei viel geringeren Problemen ein Fragezeichen über den Köpfen der Anwender gehangen wo dann in die Runde gefragt wurde ob es ein Bug oder ein Feature ist. So verbreitet denke ich ist das Phänomen dann doch nicht.
Beste Grüße
Yves

---

yves-apel.eu

Hallo Yves,

ich arbeite grundsätzlich mit dem Absatzsetzer - habe eben eine zuverlässige Silbentrennung. :-)

Und ich habe oben mehrfach betont, daß der Fehler in früheren Versionen selten erscheint. Damit komme ich klar und darüber brauchen wir nicht weiter diskutieren.

In CS5 hat der Fehler eine andere Quantität und eine andere Qualität.
So wie er sich bei mir darstellt, kann ich nicht vernünftig, sprich ökonomisch und umbruchsicher arbeiten.

Kurz: InDesign ist in der Version CS5 so für meine Arbeit - wissenschaftlicher Werksatz mit Fußnoten - nicht zu gebrauchen.

Wenn Du willst, kannst Du ja noch eine Gegenprobe mit dem Absatzsetzer machen.

Ich habe die nächsten Tage keinen Zugriff auf InDesign CS5 oder ein Musterdokument.

Viele Grüße
Martin

Antwort auf [ Martin Fischer ]

ich arbeite grundsätzlich mit dem Absatzsetzer - habe eben eine zuverlässige Silbentrennung.

Vielleicht liege ich voll daneben, aber ist diese Aussage so zu interpretieren, dass du eine Drittanbieter-Silbentrennung verwendest? Falls ja: Wie verhält sich InDesign in Bezug auf das Ausgangsproblem ohne dieses PlugIn?
Ich frage, da hier deine Anleitung – sofern ich sie korrekt nachvollziehe – nicht zu dem in Frage stehenden Fehlverhalten führt.

Frohes Schaffen!
mac_heibu

Hallo,

bei mir ist keine Drittanbieter mit im Spiel. Ich kann das Phänomen wie beschrieben nachstellen, unabhängig von:
- Silbentrennung ein oder aus.
- Ein-Zeilen-Setzer oder Absatz-Setzer
- Blocksatz, linksbündig etc.
- beliebige Einstellung für Sprache
- Mac (7.0.3) oder Win (7.0.2)

ABER:
Das Problem taucht, soweit ich sehe, nicht auf, wenn:
- in den Fußnotenoptionen "Geteilte Fußnoten zulassen" deaktiviert ist
oder
- in dem Absatz, der über die Seitengrenze hinweg geht, "Zeilen nicht trennen" "am Ende" auf 1 steht (oder ganz deaktiviert ist) Die Einstellung für "am Anfang" spielt dagegen keine Rolle.

Nicht, dass das dauerhafte Lösungen wären ...

Grüße, Martin
--
Martin Heise
http://www.martinheise.de

Hallo mac_heibu,

oben hatte ich erwähnt, dass das Problem sowohl bei InDihyph-Silbentrennung (Deutsch, Latein) als auch bei Proximity (Französisch) auftaucht.

Habe nun testweise mal alle Plugins von Drittanbietern, darunter auch InDihyph, aus dem Plugins-Ordner rausgenommen.

Das Problem lässt sich weiterhin wie oben beschrieben nachstellen und scheint demnach unabhängig von der Silbentrennung aufzutreten (Silbentrennung ein/aus im Absatzformat getestet).

Mit Absatz- und mit Einzeilensetzer.

Allerdings mit einem Unterschied: beim Absatzsetzer bewirkt die folgende Zuweisung eines anderen Zeichenformats, dass sich der vorherigen Zuweisung eines Zeichenformats geleerte Rahmen wieder füllt.
Beim Einzeilensetzer bleibt der Rahmen leer.
Man muss die Größe des Rahmens kurzfristig ändern, damit der Text wieder erscheint.

Ferner ist mir aufgefallen, dass bei den Umbruchoptionen Zeilen zusammengehalten werden müssen (unabhängig vom verwendeten Setzer).

Ist Zeilen nicht trennen nicht gewählt, dann lässt sich das Problem nicht reproduzieren.

Im Anhang ein Beispieldokument, wo sich das Problem beliebig reproduzieren lässt, indem man z.B. dem Wort »begehrt« das Zeichenformat »Zeichenformat 1« zuweist.

Viele Grüße
Martin

Hallo Martin,

Antwort auf:

Das Problem taucht, soweit ich sehe, nicht auf, wenn:
- in den Fußnotenoptionen "Geteilte Fußnoten zulassen" deaktiviert ist
oder
- in dem Absatz, der über die Seitengrenze hinweg geht, "Zeilen nicht trennen" "am Ende" auf 1 steht (oder ganz deaktiviert ist) Die Einstellung für "am Anfang" spielt dagegen keine Rolle.

Diese beiden Punkte kann ich genau so bestätigen.
Aber nein, Hurenkinder nehme ich als Erlösung von diesem Problem nicht in Kauf. ;-)

Viele Grüße
Martin

Hallo Martin,

Antwort auf:

Im Anhang ein Beispieldokument, wo sich das Problem beliebig
reproduzieren lässt, indem man z.B. dem Wort »begehrt« das
Zeichenformat »Zeichenformat 1« zuweist.

Bei mir, unter Windows, funktioniert es auch ;-(

Gut, dass ich nicht mit automatischen Fußnoten
arbeite.


Gruß
Quarz

----------------------------------------------------------
InDesign CS4 6.05 + CS5 7.02 | Win7/64 Prof.

Hallo Quarz,

schön, daß es bei Dir auch klappt mit der Herstellung des Fehlers.

Zitat

Gut, dass ich nicht mit automatischen Fußnoten arbeite.

Ja, da bringst Du mich auf eine interessante Idee.

Mit den dynamischen Endnoten von Peter Kahrel (als Fußnoten) läßt es sich bestimmt sicherer in InDesign CS5 arbeiten. Und man hat damit auch gleich das Problem der mangelnden Unterstützung von Fußnotenverweisen aus Tabellen gelöst.

Das Handling mit den beiden Rahmen für Text und Fußnoten hat man noch von dem DTP-Erstling, PageMaker, her in den Fingern.

Viele Grüße
Martin

Hallo Martin,

deine Testdatei bringt auch bei mir das (nicht) gewünschte Ergebnis. Baue ich allerdings das Dokument genau nach, und importiere sogar die Formate von deinem Dokument, kann ich die Situation nicht nachstellen.

Ich bin schon gerade dabei den Bug report zu tippen und eine E-Mail für indesignsecrets zu verfassen.
Beste Grüße
Yves

---

yves-apel.eu

Hallo Yves,

kannst Du mir mal eine von Dir neu angelegte Datei zukommen lassen, damit ich prüfen kann, ob sich mit dieser der Fehler auch bei mir nicht nachstellen lassen kann?

Das hieße dann, daß ich den Fehler eventuell in meiner Grundkonfiguration, die sich ans Dokument vererbt, zu suchen habe.

Viele Grüße
Martin

Hallo Martin,

hier ist dann mal meine Datei. Sehr Kurios ist dass ich mir mal eine Testversion von InDesign auf dem PC installiert habe, auf dem jetzt der Fehler auftritt. Auf dem Mac kommt der Fehler mit gleicher Datei nicht vor.

Eindeutig ist dass da ein Bug ist. Deine Anleitung zwingt InDesign auch zur Reproduktion vom Fehler. Nur scheint es aber irgendwo eine Systemkomponente zu geben welche den Fehler auch aussetzen lässt. Ich wüsste allerdings nicht welche. Ausser ScribeDOOR sind derzeit keine Zusatzdienste auf InDesign Macintosh installiert. Auch ist kein Zusatzprogramm enthalten wo mir bewusst wäre dass es einen Einfluss darauf hätte.

Auf jeden Fall ist der Bug Report an Adobe schonmal weg. An der E-Mail bin ich noch dran.
Beste Grüße
Yves

---

yves-apel.eu

Hallo Yves,

danke für Deine Datei.

Bei mir hat's nach der Auszeichnung von Text im überlaufenden Absatz mit einem Zeichenformat den zweiten Textrahmen auf Anhieb geleert: Bildschirmfoto.
Also dasselbe Verhalten wie bei Dateien, die ich selbst anlege.

Danke auch für Deinen Bugreport.

Meinst Du, wir sollten die neuen Erkenntnisse hinsichtlich der Reproduzierbarkeit des Problems im Zusammenhang mit Fußnotenverweisen, die einen Umbruch einer Textzeile in den nächsten verknüpften Textrahmen erzwingen auch in der Diskussion im InDesign-Forum von Adobe veröffentlichen?
Schließlich sind Problem und Opfer international. ;-)

Viele Grüße
Martin

Hallo Martin,

da du ja bereits im Adobe Forum geposted hast, kannst du die neuen Erkenntnisse auch gerne dort veröffentlichen. Ich bin zugegebenermassen dort derzeit nicht aktiv, da mir einfach die Zeit fehlt dieses Forum zu überwachen.

Einen Versuch ist es aber allemal Wert. Schaden wird es wohl nicht.

Ich weiss wirklich nicht warum bei meinem Mac System, der Fehler bei neu angelegter Datei nicht vorkommt. Ich habe mich schon gefragt ob es damit zusammenhängt dass ich den Computer erst kürzlich komplett neu aufgesetzt habe und direkt die letzte Version vom System sowie der Creative Suite aufgespielt wurde. Ich kann es wirklich nicht sagen, warum es so ist. Auch ist mir die Frage gekommen ob nicht eventuell das Programm PopCharX den Fehler reduziert, da es im Hintergrund läuft und das auslesen der aktuell verwendeten Schrift eingestellt ist. Dieser Gedanke ist allerding extrem unrealistisch.
Beste Grüße
Yves

---

yves-apel.eu

Hallo.
Ich habe als kleine Sonntagmorgen-Übung Deine Versuchsanordnung, Martin, (hoffentlich richtig) nachgestellt. Siehe Anhang.
Wenn ich in der letzten Textzeile der linken Seite ein Zeichenformat anwende, wird es sauber umgesetzt, der Folgerahmen leert sich nicht.
MacOS 10.6.4, InDesign 7.0.3.
Das ID-Dok findet sich hier.
Grüße, Jochen

Hallo Jochen,

könntest Du mal kurz aus der vierzeiligen Fn 2 einen Drei- und danach einen Einzeiler machen?
Was steckt in den Umbruch-Optionen beim umlaufenden Absatz?

Vielleicht sollten wir auch noch ein Auge auf die Eigenschaften des verwendeten Objektstils bzw. den Objekteigenschaften der Textrahmen werfen. Beim Austausch über IDML können sich gerade dort Abweichungen gegenüber dem Original in der InDesign-Datei einschleichen, die die Umsetzung des Fehlers möglicherweise begünstigen oder verhindern.

Viele Grüße
Martin

Umbruchoptionen anbei.
1, 2, 3 Zeilen: kein Effekt.
Objektstil: "Ohne". ohne Plus.
Grüße, Jochen

Hallo Jochen,

Du hast mich fast verblüfft.
Mit Deiner INDD hatte ich Mühe, das Problem nachzustellen.

Aber nachdem ich
1. Umbruchoptionen "Zeilen nicht trennen" aktiviert,
2. Fußnotenoptionen "Geteilte Fußnoten zulassen" aktiviert, und vor allem
3. Fußnotenoptionen "Abstand zwischen Fußnoten" auf 0 gesetzt habe,

kann ich das Problem am Ende auch gut mit Deiner Datei nachstellen. ;-)

Möchtest Du es mit der überarbeiteten Datei versuchen?

Viele Grüße
Martin

Ich habe Deine 3 Neuerungen in meiner Datei eingeführt.
Wir sprechen von der umbrechenden Zeile.
Ich beobachte dort jetzt folgende Regel (?): Jeder Eingriff, der InDesign veranlasst, den Umbruch neu zu starten, scheint zur Leerung der rechten Seite zu führen.
Aber das ist nur die halbe Wahrheit: Der nachfolgende Eingriff – ich meine nicht "Zurück" – füllt die Seite wieder! Und so fort: Eingriff – Leerung. Nächster Eingriff: Füllung. Nächster Eingriff: Leerung.
Grüße, Jochen

Ja, Jochen, das Hin und Her von Leeren und Befüllen funktioniert mit dem Absatzsetzer.
Mit dem Einzeilensetzer funktioniert - wie oben beschrieben - nur das Leeren.

Und die Zuweisung eines ZF war nur eine Vereinfachung der Anleitung.
Es ist - wenn ich mich recht entsinne - mit jeder Formatierung, die eine Neuberechnung des Umbruchs auslöst, möglich.

Viele Grüße
Martin

Hallo Martin,

wir stehen vor der Entscheidung, alle Rechner auf Indesign CS5 umzurüsten. Bisher haben wir mit CS3 gearbeitet, insofern wäre der Sprung schon verlockend. Allerdings schrecken mich Eure Berichte über die plötzlich auftauchenden leeren Rahmen ab. In CS3 tauchte das Problem zwar selten auf, aber allein das Wissen, dass es auch noch fünf Minuten vor Druckabgabe auftreten könnte, war schlimm genug. Weißt du, ob es von Adobe mittlerweile eine Lösung gibt?

Boni

PS. Danke für deine Berichte

Hallo Boni,

nein, ich weiß nichts von einer Lösung.

Nach einem erneuten Anlauf letzte Woche in CS5 (hatte mit einer 1:2 Umbruchzeilen-Definition bei den Fußnoten vergeblich gehofft, seltener mit leeren Seiten gestört zu werden) bin ich erst heute wieder wg. diesem Problem mit einem 1.000-seitigen Buchprojekt nach CS4 umgesiedelt. Das geht allerdings ohne große Reibungsverluste.

Beim Mengensatz wiegen die wenigen verlockenden Vorteile von CS5 (spaltenübergreifende Absätze, unterteilte Spalten) die Nachteile, die mit dem hier diskutierten Fehler verbunden sind, nicht auf.

Für Mengensatz ist in meinen Augen InDesign CS4 das beste InDesign, das es gibt.

CS5 nutze ich fortan nur noch für graphisch diffizilere Aufgaben etwa bei der mehrseitigen Anlage von Buchumschlägen oder mehrspaltigen Registern mit spaltenübergreifenden Überschriften.

CS5 soll auch besseren (fehlerbereinigten) Code für ePub liefern.

Der Import von Word-Daten mit Fußnoten und Register-Einträgen hat sich in CS5 gegenüber CS4 verbessert. Allerdings ist unter bestimmten Umständen immer noch ein Import der Word-Daten in InDesign CS3 die bessere Wahl – auch gegenüber CS5.

Antwort auf:

wir stehen vor der Entscheidung, alle Rechner auf Indesign CS5 umzurüsten.

Ich empfehle dringend, vor der Umrüstung aller Rechner auf CS5 eine Demo-Version herunterzuladen und für den eigenen Bedarf auf Herz und Nieren zu testen.

Was für Produkte stellt Ihr mit InDesign her?

Viele Grüße
Martin

Hallo Boni,

ich bin zwar nicht Martin kann jedoch berichten daß ich nichts weiteres von Adobe gehört habe. Wundert mich jedoch auch nicht, da bis jetzt nicht ein Feedback zu den vielen Bug Reports und Feature Requests gekommen ist. Auch David und Anne-Marie von indesignsecrets nehmen keine Stellungnahme.

Auch unter den "Bekannten Problemen" taucht der Fehler noch nichtmal auf. Irgendiwe komisch daß das letzte Änderungsdatum von dem Dokument noch vor dem Release von InDesign CS5 stammt.

Ich fürchte wir müssen wikileaks darauf ansetzen um zu erfahren was intern bei Adobe läuft ;-)
Beste Grüße
Yves

---

yves-apel.eu

Hallo Martin,

ich habe mal die langen Dokumente bei uns in der Firma überprüft und weiß jetzt warum der Fehler unter meinen Arbeitskollegen nahezu unbekannt ist.

Die Fussnotenoption "Geteilte Fußnoten zulassen" ist bei uns zu 99% ausgeschaltet. Es gab durchgehend ein negatives Feedback, wenn Fußnoten aufgeteilt wurden. Unsere Kunden mögen dies einfach nicht. Es ist zwar keine Lösung, da diese Einstellung ihre Darseinsberechtigung hat. Diese Info kann aber als Entscheidungshilfe dienen.

EDIT: die ePub Konvertierung ist deutlich besser als in CS4, jedoch noch immer nicht das Gelbe vom Ei.
Beste Grüße
Yves

---

yves-apel.eu

Dann müssen wir wohl doch noch auf die nächste Version warten :–(((
Wir setzen umfangreiche wissenschaftliche Bücher (200-1000 Seiten) fast immer mit Fußnoten, auch mit Tabellen und Register. Die Fußnotenteilung müssen wir zulassen. Insofern würden uns alle im Forum vorgeschlagene Lösungsumwege nicht wirklich helfen. Schaaade!
Die Testversion habe ich bereits runtergeladen. Würde ich irgendwie mit einer in CS5 erstellten Datei auch in CS3 arbeiten können? Vielleicht über Interchange-Format?

Danke für Eure Einschätzungen!
Boni

Hallo Boni,

Antwort auf:

Dann müssen wir wohl doch noch auf die nächste Version warten :–(((

Du hast also die Hoffnung noch nicht aufgegeben? ;-)
Aufgrund des Stillstands bei der Entwicklung der Fußnotenfunktion seit deren Einführung in CS2 bin ich in diesem Punkt pessimistisch. Adobe konzentriert sich auf andere Ziele und Zielgruppen.

Außerdem vermute ich einen Zusammenhang des diskutierten Fehlers mit den in CS5 neu implementierten Funktionen 'Spaltenspanne' und 'Unterteilte Spalte', die stark in die Umbruchsteuerung eines Absatzes eingreifen.
Offensichtlich ist diesem Fehler nur schwer beizukommen oder er wird – wie Yves gezeigt hat – einfach ignoriert. :-(

Antwort auf:

Würde ich irgendwie mit einer in CS5 erstellten Datei auch in CS3 arbeiten können? Vielleicht über Interchange-Format?

Das geht nicht an CS4 vorbei, denn CS5 kann kein INX und CS3 kein IDML.
CS4 kann beides – nach oben und nach unten.

Viele Grüße
Martin

Antwort auf [ Martin Fischer ]

Das geht nicht an CS4 vorbei, denn CS5 kann kein INX und CS3 kein IDML.
CS4 kann beides – nach oben und nach unten.

das bestätigt, dass wir uns gerade richtig entschieden haben. Wir werden CS5 links liegen lassen und stattdessen CS4 kaufen. Besser später als nie! :-)
Danke noch mal!

Boni

Hallo Martin,

ich habe Deine Test_leererRahmen-Datei nachgebaut (InDesign 7.03, Windows XP).
Dabei habe ich festgestellt, dass bei mir der Bug bei der Eingabe des Zeilenabstandes im Absatzformat 08 FN loslegt.

Ab einem Zeilenabstand von 10,25 und größer im Format 08 FN verschwindet bei mir der Bug. Der Zeilenabstand im Format 01 Normal muss aber mindestens so groß sein wie oder größer sein als der automatische (14,4pt).

Ändere ich andererseits den Zeilenabstand im Format 01 Normal auf z.B. 15pt, tritt bei mir auch bei deinem Abstand von 9pt in der Fußnote der Bug nicht auf, der Abstand kann jetzt sogar noch kleiner werden.

Das ist schon ein seltsames Käferchen.

Albert Schmitt

Hallo Albert,

wie kommst Du auf so eine abgefahrene Versuchsanordnung? ;-)

In der Tat konnte ich ersteres (FN-Zeilenabstand > 10,25 pt) auf dem Mac kurzzeitig nachbilden (kein Fehlverhalten mehr).

Danach versuchte ich Deine zweite Bedingung (Normal-Zeilenabstand >= 15 pt).
Das hat dann nicht mehr funktioniert (Fehler trat bei Zuweisung eines ZF im Wechsel auf).

Hinterher ließ sich auch die erste Versuchsanordnung nicht mehr verifizieren.

Immerhin scheint eine gewisse Abhängigkeit des Auftretens des Fehlers von anderen Eigenschaften im Absatzformat gegeben zu sein.

Viele Grüße
Martin

Hallo Martin,

abgefahrene Versuchsanordnungen stecken einem alten PageMaker-Benutzer im Blut. ;-)

Ich bin jetzt der Meinung, dass der Bug mit der durch die Fußnote erzwungenen Verschiebung der letzten Zeile auf die nächste Seite zusammenhängt.

Mir scheint, die „vertriebene“ Zeile versucht bei jeder Änderung in „ihrem“ Absatz an ihren angestammten Platz zu gehen und da die Fußnote das verhindert, springt sie frustriert eben auf die nächste Seite und reißt dabei die restliche Seite mit.

Meine Gründe für diese Vermutung:

Ich kann in deiner Datei den Bug nur in diesem Absatz auslösen. Alle anderen Absätze sind „gesund“. Teile ich den zweiten Absatz nach dem ersten Satz in zwei Absätze, so ist der jetzt zweite Absatz „gesund“, im jetzt dritten mit der Fußnote kann ich weiter zuverlässig den Bug auslösen.

Das hat mich zu folgenden Versuchen gebracht:

Ich habe nach dem ersten Absatz eine Leerzeile eingefügt
oder
in den Fußnotenoptionen den Abstand vor der ersten Fußnote auf vier oder fünf Millimeter erhöht
oder
die Höhe des ersten Textrahmens von 132,667 mm auf 132 mm oder weniger verringert.

Jede dieser Aktionen hat bei mir den Käfer vertrieben. Da dabei immer der Raum über der ersten Fußnote verringert wurde, bin ich auf eine weitere Möglichkeit verfallen.

Ich habe eine kleinen Textrahmen (4 mm Höhe, 10 mm Breite) aufgezogen, ihn in den freien Raum über der ersten Fußnote gelegt und ihm Textverdrängung 0 mm oben und unten gegeben. Weg war der Bug.

Wenn jemals ein Bugfix kommt, solltest Du also unbedingt per Script überprüfen, ob da plötzlich hunderte leerer Textrahmen dazugekommen sind. ;-)

Keiner meiner Versuche ist natürlich eine Lösung, aber solltest Du sie nachvollziehen können, wäre der Bug zumindest ein bisschen eingekreist.

Albert Schmitt

Hallo Albert,

vielen Dank für Deine Mühe.

Zitat

Mir scheint, die „vertriebene“ Zeile versucht bei jeder Änderung in „ihrem“ Absatz an ihren angestammten Platz zu gehen und da die Fußnote das verhindert, springt sie frustriert eben auf die nächste Seite und reißt dabei die restliche Seite mit.

Es war gegen Ende der achtziger Jahre, da glaubte ich als Jungspunt noch, man könnte sich das Setzen ganz einfach machen und gelieferte Daten in Word (auf dem Mac) ein bisschen gestalten. Und dabei ist mir genau das von Dir beschriebene Phänomen in die Augen gesprungen:

Zeile mit Fußnotenverweis passt nicht mehr unten auf die Seite (wg. der Fußnote), also verschiebe Zeile mitsamt der Fußnote auf die nächste Seite. Jetzt ist genügend Platz für die Textzeile, also wieder zurück. Doch diese zieht die Fußnote auch wieder zurück usw. In Word konnte ich diese Unentschlossenheit zu meiner Belustigung (und die meiner Kollegen) live beobachten. Ohne eigenes Zutun immer wieder hin und her. Ein flackernder Monitor.

Damals hat mich eben dieses Verhalten davon überzeugt, dass Word für die Herstellung eines konsistenten Umbruchs nichts taugt (der Umbruch änderte sich meiner Erinnerung nach auch mit dem Wechsel des Standarddruckers an unterschiedlichen Arbeitsplätzen und – gefühlt – sogar nach Tagesform), sondern dass statt dessen ein vernünftiges Satzprogramm vonnöten sei.

Und nach all den Jahren mit Ventura Publisher, PageMaker, CCS Textline, VivaPress und InDesign begegnet mir ein ähnlicher Fehler (Unentschiedenheit bzgl. der Platzierung einer Textzeile mit Fußnotenverweis) nun wieder.

Ich hoffe, ich muss heute nicht zum selben Schluss kommen wie damals. ;-)

Antwort auf:

Keiner meiner Versuche ist natürlich eine Lösung, aber solltest Du sie nachvollziehen können, wäre der Bug zumindest ein bisschen eingekreist.

Albert, es ging mir nicht in erster Linie darum, den genauen Zusammenhang mit den Fußnoten und die fehlerauslösenden Bedingungen nachzuweisen.
Während der ersten Hälfte der Diskussion wurde von anderen Teilnehmern immer wieder darauf hingewiesen, dass der Fehler auch unabhängig von Fußnoten in fußnotenlosen Texten auftaucht.

Mir ging es darum, eine arbeitsplatz- und systemunabhängige Situation aufzuzeigen, in der dieser Fehler auch für andere nachvollziehbar auftaucht. Und das war in der Fußnotensituation – nachdem es einmal so ermittelt war – relativ einfach zu bewerkstelligen.
Für die anderen Fälle, die nicht in einem Zusammenhang mit den Fußnoten stehen, konnte ich noch keine auslösenden Bedingungen eingrenzen, die das Problem reproduzieren lassen.
Die gibt es aber auch.

Es ist nach meinem Verständnis nicht Aufgabe eines Anwenders, allen möglichen auslösenden Faktoren eines Fehlers insgesamt auf die Schliche zu kommen. Es reicht m.E., den Fehler zu benennen und – als Dreingabe – die Situation etwas näher zu beschreiben und einzugrenzen.

Um den Rest sollen sich die Entwickler der Software kümmern.

Es scheint allerdings ein Transportproblem zu geben.

Viele Grüße
Martin

Hallo ihr Verzweifelten,

ich habe das Thema jetzt längere Zeit ruhen lassen und muss mich jetzt doch wieder einklinken. Ich habe ja am Anfang alles losgetrampelt, damit das Problem zuerstmal erkannt werden kann. Nachdem Martin sich "damals" schon vor mir damit herumgeplagt hat, gab es dennoch Zweifler. In diversen Versuchen haben wir dann erläutert, wann das Problem auftritt.

Antwort auf [ Jochen Uebel ]

Ich beobachte dort jetzt folgende Regel (?): Jeder Eingriff, der InDesign veranlasst, den Umbruch neu zu starten, scheint zur Leerung der rechten Seite zu führen.
Aber das ist nur die halbe Wahrheit: Der nachfolgende Eingriff – ich meine nicht "Zurück" – füllt die Seite wieder! Und so fort: Eingriff – Leerung. Nächster Eingriff: Füllung. Nächster Eingriff: Leerung.

Das was Jochen schreibt, wurde auf den ersten Seiten dieses Threads schon abgehandelt und erkannt. Das ist natürlich kein Vorwurf an Jochen, da man nicht erwarten kann, dass jeder jeden einzelnen Beitrag liest … es ist nur eine weitere Bestätigung dieser ganz großen Komödie.

Martins neuesten Versuchsablauf habe ich bewusst noch nicht ausgeführt, da mir meine eigenen, simplen Versuche gereicht haben. Ich habe jetzt noch eppileptische Anfälle vom "blinken" der Seiten und bin dementsrpechend verärgert. Dass 7.0.3 keine Abhilfe gebracht hat, überrascht mich auch nicht.

Zu hören, dass jetzt mehrere Firmen/Personen nicht auf CS 5 Umsteigen, ist zum Einen enttäuschend, zum Anderen aber ein sehr wichtiges Zeichen für Adobe. Wenn sie es nur sehen könnten…

Frage: Können wir etwas bewegen, wenn sich mehrere Benutzer im Adobe Forum anmelden und dort kurz und bündig verkünden, dass diese Problematik den Ruf von Adobe schädigt?

Ich habe unter diesem Thread http://forums.adobe.com/message/3338675 soeben folgendes geschrieben (leider weiß ich nicht, ob dieser Thread der aktuellste und wichtigste zu diesem Problem ist):

Zitat

Without skirting around the issue I have to agree with all of the preceding posts. I have met several companies and users that will definitely NOT switch to InDesign CS5 after getting involved with this issue. If Adobe doesn't address this issue quickly, they will loose the trust of many professional typesetters.

It seems that Adobe doesn't take notice of this problem although they received several bug reports about it. We – as the user base – will do our best to spread the word about this severe issue when using footnotes results in arbitrary empty pages. We would be glad if Adobe would at least respond to our inquiries.

Die Anmeldung bei Adobe ist einfach und geht schnell. Man kann nach der Anmeldung sofort im Forum schreiben.

So, jetzt noch ein kurzer Nachtrag: Martins Versuchsaufstellung habe ich nun nachgebaut. Komme genau zu dem enttäuschenden Ergebnis. Seite voll, Seite voll, Seite leer…

Hallo Otoya,

Antwort auf:

Martins Versuchsaufstellung habe ich nun nachgebaut. Komme genau zu dem enttäuschenden Ergebnis. Seite voll, Seite voll, Seite leer…

Das war der Sinn der Anleitung: die Reproduktion des Problems unter bestimmten, in der Praxis relevanten Bedingungen.

Gewiss gibt es auch andere Situationen, in denen sich das hier diskutierte Problem zeigt. Aber so, wie im Zusammenhang mit den Fußnoten beschrieben, lässt es sich beliebig nachstellen.

Ein entsprechender Hinweis wurde von verschiedener Seite an Adobe in Form eines Bugreports zugestellt.

Yves hat dies zudem in einem Video aufgezeichnet und dieses an Adobe wie auch an InDesign Secrets weitergeleitet.

Eine Antwort auf diese klaren Berichte und deutliche Dokumentationen steht noch aus.

Viele Grüße
Martin

Hallo,

Zitat

Yves hat dies zudem in einem Video aufgezeichnet und dieses an Adobe wie auch InDesign Secrets weitergeleitet.
Eine Antwort auf diese klaren Berichte und deutliche Dokumentationen steht noch aus.

Ich denke dass die Antwort auch ausbleiben wird.

Änlich wie Otoya habe ich Adobe mittlerweile auch eine (nicht öffentliche) E-Mail geschickt mit Anmerkungen zu dem was ich von Adobe's Bug Report/Feature Request halte und was dieses Formular für einen Sinn hat wenn man kein Feedback bekommt. Auch dazu gibt es kein Statement seitens Adobe.

Ich zumindest für meinen Teil habe mich entschlossen dieses Formular nicht mehr auszufüllen. Wenn ich jetzt ein Problem mit InDesign (hinsichtlich eines Bug's) habe, wende ich mich direkt an den Support.
Beste Grüße
Yves

---

yves-apel.eu

Hallo Yves,

Antwort auf:

Änhlich wie Otoya habe ich Adobe mittlerweile auch eine (nicht öffentliche) E-Mail geschickt mit Anmerkungen zu dem was ich von Adobe's Bug Report/Feature Request halte und was dieses Formular für einen Sinn hat wenn man kein Feedback bekommt. Auch dazu gibt es kein Statement seitens Adobe.

Ich kann nur bestätigen, dass es auf die Dauer demotivierend wirkt, wenn die Kommunikation nur in einer Einbahnstraße erfolgt und von der anderen Seite nichts als gähnendes Schweigen zu vernehmen ist.

Allerdings wird bei verschiedenen Events mit Beteiligung von Vertretern von Adobe immer wieder allgemein darauf hingewiesen, wie wichtig diese Rückmeldungen sind und wie sehr sie in die Planung und Entwicklung künftiger Versionen hineinwirken.

Nichtsdestotrotz könnten aus meiner Sicht direkte Antworten an eine bestimmte Person oder an einem größeren Kreis, etwa in einem Forum, die Bindung von engagierten Kunden positiv beeinflussen und stärken.
Das dürfte im Sinne einer direkten Rückkopplung im Einzelfall sogar stärker wirken als das aufmunternde Auftreten von Motivatoren bei großen Events.

Antwort auf:

Wenn ich jetzt ein Problem mit InDesign (hinsichtlich eines Bug's) habe, wende ich mich direkt an den Support.

Und was weiß der Support zu diesem Bug zu sagen?

Viele Grüße
Martin

Sicher ist unter den Mitlesern der eine oder die andere Teilnehmer(in) des Prerelease Programms (ich eingeschlossen). Dort schon einen Bug-Report hinterlassen? Mir fehlt im Moment die Zeit.
Grüße, Jochen

Die Diskussion um diesen Fehler ist inzwischen alt und sehr, sehr umfangreich.

Trotz der vielen Versuche, diesen Fehler seit nunmehr über einem Jahr(!) öffentlich und bei Adobe bekannt zu machen (Diskussionen in mehreren Foren, bug reports von vielen Anwendern, detaillierte Anleitung zur Reproduktion des Fehlers, Videopräsentation von Yves Apel, Meldung an InDesign Secrets) ist bis dato von der Entwicklerseite keine Reaktion, geschweige denn eine Verbesserung und schon gar keine Behebung zu verzeichnen.

Dieser Bug ist noch nicht mal in die Liste der known issues and bugs aufgenommen worden!

Es scheint so, als würde dieser Bug einfach ignoriert.
Das enttäuscht und frustriert nicht nur mich anhaltend.

Aus meiner Sicht handelt es sich um einen gravierenden Bug.
Einzig und genau dieser Bug verunmöglicht es mir (und offensichtlich auch anderen Mengensetzern), CS5 und CS5.5 zur Erstellung von Werksatz einzusetzen und willkommene neue Funktionen produktiv zu nutzen.

Die finanziellen Ausgaben für CS5+ und zusätzliche Plugins für CS5+ sowie der Aufwand für die Einarbeitung sind für uns Mengensetzer auch nach mehr als 12 Monaten Wartezeit auf eine Lösung umsonst getätigt worden.

CS5 dient mir somit lediglich als Konvertierungswerkzeug beim Import von DOCX-Dateien für CS4, da diese in CS5 mit weniger Fehlern als die DOC-Dateien in CS4+ platziert werden. :-(



Im englischsprachigen Adobe InDesign Forum ist die Diskussion über diesen Bug – ebenso hilflos wie ohne neue Erkenntnisse oder Workarounds – erneut aufgeflammt – mit der Bitte um Herstellung einer breiteren Öffentlichkeit.

Zitat

In my tests CS 5.5 does NOT fix the issue. And it also is worrying that this forum thread has only a few posts yet.
There must be many more typesetters with this problem which can hardly stay unnoticed. Raise your voice.

Ich bin dabei und erhebe hiermit heiser meine Stimme.



P.S.:
Das Video von Yves Apel, das den Prozeß des Bugs (das Leeren des Textrahmens) deutlich veranschaulicht, kann online angesehen werden: InDesign - Empty Frame Bug.

Viele Grüße
Martin

Ich muss da andere Erfahrungen anmerken:
1. Dieser Bug ist Adobe bekannt und wurde mir in einer persönlichen, privaten E-Mail bestätigt, die allerdings nicht vollständig zitieren kann. Es gab zuvor einen Austausch betroffener Dokumente und eine Diskussion darüber.
2. In der selben E-Mail wurde beschrieben, dass die Behebung dieses Bugs eine umfangreiche Umprogrammierung erfordert und deshalb erst mit einer neuen Version, nicht bei einem Bugfix, zu rechnen sei, weil die Codeänderung innerhalb eines Zykluses zu gefährlich für einen Rattenschwanz neuer Bugs wäre.
3. Der Bug tritt übrigens seit CS2 auf, nicht erst seit CS5. Auch das wurde bestätigt.

Hallo Herr Adelberger,

Antwort auf:

1. Dieser Bug ist Adobe bekannt und wurde mir in einer persönlichen, privaten E-Mail bestätigt

Dies ist der erste öffentliche Hinweis, dass Adobe von diesem Bug Notiz genommen hat.

Ich danke Ihnen dafür.

Antwort auf:

2. In der selben E-Mail wurde beschrieben, dass die Behebung dieses Bugs eine umfangreiche Umprogrammierung erfordert und deshalb erst mit einer neuen Version, nicht bei einem Bugfix, zu rechnen sei, weil die Codeänderung innerhalb eines Zykluses zu gefährlich für einen Rattenschwanz neuer Bugs wäre.

3. Der Bug tritt übrigens seit CS2 auf, nicht erst seit CS5. Auch das wurde bestätigt.

Dann war er den Zuständigen vor CS5 entweder noch nicht bekannt oder er wurde in seiner Wirkung unterschätzt und auch in CS5 in Kauf genommen.

Von den Betroffenen wurde immer wieder darauf hingewiesen, dass der Bug in CS5 nicht neu bzw. zum ersten Mal aufgetreten ist, sondern auch in früheren Versionen zu beobachten war (s. der Beginn dieses Diskussionsfadens). Entsprechende Bugreports wurden bereits vor CS5 eingereicht. Er sollte damit auch den Entwicklern bereits vor CS5 bekannt gewesen sein.

Neu ist das Ausmaß der Häufigkeit des Auftretens in CS5, das ein vernünftiges Arbeiten in Indesign CS5 mit langen Texten und Fußnoten nicht mehr zuläßt.
In CS4 und darunter trat dieses Ereignis nur sehr selten zu Tage und konnte indirekt durch Textüberlauf erkannt und durch Sichtung der verknüpften Textrahmen lokalisiert und dort behoben werden.

Bei CS5 hingegen konnte ich beobachten, dass die Korrektur des Fehlers an einer Stelle das Erscheinen an einer anderen provozierte. Ich hatte Manuskripte in CS5 in Bearbeitung, die sich unmittelbar vor dem Ausdruck nicht ohne einen Hinweis auf einen Textüberlauf an irgend einer neuen Stelle ausdrucken ließen. Das Feuer, an einer Stelle gelöscht, brach sofort an einer unerwarteten Stelle wieder aus.

Die sicherste Lösung: Export in IDML und Weiterarbeit in CS4.

Ich hatte sehr großes Interesse, bestimmte neue Funktionen von CS5 zu nutzen und persönlich viel Zeit, Überlegungen und Versuche dran gesetzt, den Auslöser einzukreisen und einen Workaround zu finden, mit dem sich arbeiten ließe. Die Diskussion oben zeigt, dass zumindest eine Situation gefunden werden konnte, in welcher der Fehler sich gezielt reproduzieren läßt. Aber sie zeigt auch, dass bislang kein Workaround zur Entschärfung dieses Fehlers entwickelt werden konnte.

Es ist für die vielen Betroffenen immerhin ein schwacher Trost, dass das Problem zur Kenntnis genommen wurde und Hoffnung auf eine Lösung in einer künftigen Version besteht.
Für CS5 bleibt uns wahrscheinlich nur die Erfahrung einer großen Enttäuschung.

Viele Grüße
Martin

Inzwischen ist etwa ein Jahr vergangen.
Wir hatten heute ein ähnliches Phänomen (keine Leere Seite sondern "nur" eine verschwundene Fußnote am Seitenende) und sind dabei auf diese Diskussion gestoßen.

Gibt es schon neue Erkenntnisse?

Hallo Werksetzer,

laut Wilhelm Adelberger ist der Fehler in CS6 behoben: Leere Seiten bei Fußnoten in CS6

Dies kann ich insofern bestätigen, als dass mir der Fehler in meinen noch wenigen CS6-Büchern noch nicht untergekommen ist.

Mit einer Behebung des Fehlers in CS5 und CS5.5 ist nach Erscheinen von CS6 nicht mehr zu rechnen.

Viele Grüße
Martin

Hallo Martin,

erstmal Danke für die schnelle Antwort. Adobe hätte das nicht hinbekommen ;)

Das ist ja mal ne prima Nafhricht.
Dann muss ich ja nur noch knapp 2000 Euro für ein paar Updates ausgeben, damit auch die Werke mit Fußnoten funktionieren.

Aber vielleicht sollte ich vorher noch nachlesen, ob Adobe irgendetwas anderes nützliches wieder abgeschafft oder versaubleutelt hat ...

Liebe Grüße
Werksetzer

Hallo,

Antwort auf [ Martin Fischer ]

laut Wilhelm Adelberger ist der Fehler in CS6 behoben: Leere Seiten bei Fußnoten in CS6

Dies kann ich insofern bestätigen, als dass mir der Fehler in meinen noch wenigen CS6-Büchern noch nicht untergekommen ist.

Gestern hatte ich mich bewusst vorsichtig ausgedrückt.
Und prompt werde ich heute dafür mit einem 'plötzlich leeren Textrahmen' belohnt. ;-)

Es handelt sich dabei nicht um die (in CS5/5.5 reproduzierbare) Konstellation mit einer Fußnote und best. Umbruchregeln (Schusterjungen; s.o.). Im betroffenen Bereich wird keine Fußnote umbrochen.

Ich ordne den beobachteten Fehler unter der Kategorie 'ähnlich wie in CS2 bis CS4' ein. Also zwar sehr selten (kein Vergleich zu CS5/5.5), aber immer noch möglich.

Der Fehler kann leicht behoben werden:
1. temporäre Veränderung der Ausdehnung des leeren Textrahmens oder
2. Änderung eines Zeichenattributs im Absatz, der nicht korrekt in den Textrahmen umbrochen wurde.

Man kann dem Fehler außer durch Sichtkontrolle über einen entstandenen Textüberlauf (der vorher nicht bestanden hat) auf die Spur kommen.

Viele Grüße
Martin

Hmmm, sowas wie im Bild kommt mir bekannt vor.
Ich lösche dann testhalber einfach den Textrahmen.
Dann wird von InDesign neu umbrochen und es passt meistens wieder ...

Hallo nach überall,

diesem alten und langen Thread füge ich noch ein posting hinzu ...

Ich bearbeite in CC ein Buch, das im Prinzip aus einer einzigen Tabelle besteht (linke Spalte: Kategorie, vielfach mehrzeilig [deshalb auch Satz als Tabelle, nicht mit hängendem Einzug]; rechte Spalte: Fließtext und Grafiken). Und habe dabei zum ersten Mal das Auftauchen der plötzlich leeren Seite erlebt. Nicht nur einmal sondern gefühlte 50 Male seit gestern.

Offenbar wird das Problem behoben durch Abwahl von "Zeilen nicht trennen" in den Umbruchoptionen (bei Tabellen ja sowieso nicht anwendbar), wie in einigen der vielen Beiträge dieses Threads beschrieben, danke!

Dass allerdings der Bug auch in CC noch existiert, ist schon frustrierend (um das mindeste zu sagen).

Beste Grüße
Doro

CC 2024 auf Windows 11

Oh no, ich habe gelogen! Obwohl ich "Zeilen nicht trennen" in allen vorkommenden AF abgewählt habe, erscheint nach Bearbeitung irgendwelcher Parameter immer wieder eine leere Seite :((
Kann es mit "Alle Textabschnitte neu umbrechen" beheben -- aber das immer machen zu müssen (und nicht zu wissen, ob an anderen Stellen auch neu umbrochen wird), ist kein sinnvoller Workflow.

Hat jemand das Phänomen in CC auch beobachtet und Abhilfe gefunden?

Grüße, Doro

CC 2024 auf Windows 11

Hallo zusammen,
konnte gerade das Problem mit einer aktuellen Version von InDesign 2021 auf Windows 10 nachstellen. Die Dateien kann ich noch nicht posten, frage aber nach. Ist ein Minimalbeispiel mit einem Textfluß, der vier Fußnoten enthält, auf einer Doppelseite. Keine Besonderheit wie Fußnotentext fließt von Spalte zu Spalte oder von Rahmen zu Rahmen.

Erkenntnis:
Das Problem tritt nicht auf, wenn die Option "Geteilte Fußnoten zulassen" in den Fußnoten-Optionen ausgeschaltet ist.
*****
Mit herzlichem Gruß,
Uwe Laubender