Hallo,

das Thema hatten wir schon mal angesprochen in »Hebräische Buchstaben laufen verkehrt herum«.

Aber da ich seitdem keine Lösung zur Vermeidung der unerwünschten Spationierungen an zufälligen Stellen bei Verwendung des Globalen Adobe Absatzsetzers gefunden habe und bei mehreren Büchern, die sich in der Produktion und kurz vor Drucklegung befinden, am Rande der Verzweiflung stehe, möchte ich das Thema nochmals hervorholen. Vielleicht kennt inzwischen jemand anderer DIE Lösung oder zumindest Entschärfungen des Problems.

Bei Verwendung des Globalen Adobe Absatzsetzers kann es zu unerwünschten Spationierungen an zufälligen Stellen kommen.

– Beispiel 1
– Beispiel 2
– Beispiel 3

Verschiedene Versuche, den Fehler zu entschärfen (weniger häufig in Erscheinung treten zu lassen), blieben ohne Erfolg:
1. Ligaturen abstellen,
2. Globaler Einzeilensetzer statt dem Globalen Absatzsetzer (manchmal hilft die alternative Zuweisung zwar kurzfristig, so wie andere typographische Änderungen kurzzeitig für das Verschwinden der unerwünschten Spatien sorgen können; aber der Fehler kann sich durch andere Änderungen im Absatz wieder einstellen);
3. Ersetzen von geschützten Wortzwischenräumen mit variabler Breite durch Leerzeichen mit dem Attribut "Kein Umbruch",
4. Erhöhen des maximalen Wortabstands im Blocksatz auf über 500% und mehr (es ist auffällig, dass der Fehler gehäuft in Zeilen mit erweitertem Wortabstand erscheint),
5. alle Zeichenabstände auf 0 %, alle Glyphenskalierung auf 100 %,
6. Vermeidung von GREP-Stilen,
7. Ausschluss und sukzessive Wiedereinschaltung von ThirdParty-Plugins,
8. Verwendung unterschiedlicher Grundschriften (es gab Stimmen, die meinten einen Zusammenhang des Fehlers mit der Minion Pro zu beobachten; der Fehler tritt bei meinen Test mit allen möglichen Schriften auf),
9. Verwendung unterschiedlicher Schriften für Hebräisch; das Problem tritt unabhängig von der Verwendung von Vokalisierungszeichen auf,
10. experimentelle Einstellungen in World Tools von InTools.

Das richtig Fiese an diesem Fehler ist, dass er ebenso überraschend wieder verschwinden *kann*, wenn irgendein Eingriff im betroffenen Absatz vorgenommen wird, wie er danach auch wieder überraschend erscheinen kann.
Und man muss schon ziemlich genau hinsehen, um den Fehler zu entdecken, besonders dann, wenn sich das Spatium an der Grenze zweier Silben befindet, die man auch leicht als zwei einzelne Worte (Wortbilder) lesen könnte.

Nach diesem Fehler lässt sich nicht suchen.
Man muss ihn gezielt mit dem Auge aufspüren.

Meine vorläufige, wirklich sehr umständliche, zeitintensive und "körperlich" anstrengende Lösung für die Herstellung von Druckdaten:
1. Erstellung einer Druck-PDF.
2. Intensive Kontrolle auf unerwünschte Spationierungen in Absätzen mit Hebräisch in einem Ausdruck der Druck-PDF.
3. Korrekur der Fehler in InDesign (manchmal ganz brutal durch Zuweisung des normalen Adobe Absatzsetzers und Umkehrung der Reihenfolge der hebräischen Zeichen per Skript) und Export von Einzelseiten.
4. In der Druck-PDF ersetzen der Seiten mit Fehlern druch die neu exportierten PDF-Einzelseiten.

Zur Geschichte des Fehlers:
===========================
Ich kann mich nicht erinnern, dass dieser Fehler jemals in der von WinSoft.fr entwickelten und vertriebenen MiddleEast-Version von InDesign CS2 ME oder CS3 ME aufgetaucht wäre.

Der Fehler ist mir erst seit der verdeckten Einführung des WorldReady Composers in InDesign CS4 (nach der ersten Begeisterung) nach und nach bekannt geworden.

In CS5 und CS5.5 blieb der Globale Absatzsetzer im normalen InDesign weiterhin versteckt (und ebenso fehlerhaft wie in CS4). Meines Wissens war die letzte von WinSoft.fr entwickelte und vertriebene MiddleEast-Version die InDesign CS5.5 ME.

Ab InDesign CS6 ist der WorldReady Composer in normalen InDesign-Versionen offen ansprech- und aktivierbar. Es gibt kein InDesign CS6 Middle East-version mehr. Der Fehler tritt in CS6 *gefühlt* häufiger auf als in CS4 (oder wird inzwischen aus der Erfahrung und der Sensibilisierung leichter entdeckt). Testweise Rückverlagerungen der Satzarbeiten in CS4 führten nicht zur erhofften Lösung. Der Fehler ist demnach bereits in CS4 angelegt.

In all den Versionen, in welchen der Globale Absatzsetzer nicht mehr von WinSoft.fr, sondern von Adobe direkt implementiert wurde, kann ich diesen Fehler entdecken (hab ich bis CS3 ME diese Fehler nur verschlafen und übersehen?). BugReports bleiben seit Jahren unerhört oder unterbewertet, keine besondere Dringlichkeit.
Die Probleme werden auch in Adobe Foren in mehreren (alten) Beiträgen (z.B. weird character spacing in paragraphs, Hebrew font spacing problem - ohne Lösung - diskutiert.

In der Creative Cloud ist es möglich, eine Hebrew/English-Version von InDesign CC zu installieren. Meine Test vor ca. einem halben Jahr waren ernüchternd: Egal ob InDesign CC Hebrew/English jungfräulich oder über ein dt. InDesign CC installiert wurde, die unerwünschte Spationierungen an zufälligen Stellen traten auch dort in Erscheinung.

Für mich wäre schon alleine die Behebung dieses Fehlers, der sich durch viele *Adobe* InDesign Versionen zieht, ein Anlass zum Sprung in die CC Abo-Abhängigkeit. Aber hier tut sich wie an vielen anderen einmal eingeführten und nicht mehr weiterentwickelten Funktionen nichts. Nicht einmal Fehlerkorrektur.

Hat inzwischen jemand eine Idee, wie man dem Fehler beikommen oder ihn entschärfen könnte?




Ansonsten möchte ich meine WinSoft.fr Middle East Version wieder zurück!

Bernd, hörst Du?
Du hast nicht zufällig noch eine unbenutzte CS5.5 ME-Box in Deinem Regal stehen? ;-)
Dir ist dieser Fehler doch gänzlich unbekannt, oder?

Viele Grüße
Martin

Antwort auf [ Martin Fischer ]

Ansonsten möchte ich meine WinSoft.fr Middle East Version wieder zurück!

Bernd, hörst Du?
Du hast nicht zufällig noch eine unbenutzte CS5.5 ME-Box in Deinem Regal stehen? ;-)
Dir ist dieser Fehler doch gänzlich unbekannt, oder?

Hallo Martin,

ja, ich höre. Tut mir leid, aber von der ME habe ich nur eine Lizenz, beginnend mit (ich glaube) ID 1.5, nach CS3 habe ich dann von ID auf eine CreativeSuite ME up-ge-gradet und auch nur die Kisten bis einschließlich 5.5. Keine CS6.

Dass ich den Fehler bislang nicht kenne, kann möglicherweise damit zu tun haben, dass ich praktisch NIE mit Blocksatz arbeite. Und ansonsten werde ich versuchen, sukzessive einige Projekte von ID ME rüber nach FrameMaker 2015 zu ziehen. War mir schon immer das liebere Programm (wenn auch leider nicht mehr auf dem Mac), und jetzt werden immerhin offiziell schon mal ARA, FAS, HEB und Thai unterstützt… deckt alles ab, was ich an komplexen Sprachen zu tun habe.

Schöne Grüße,
Bernd
---------------
cavete fenestras et nubes!

Hallo Martin,

ich hatte mit Hebräisch bisher noch nichts zu tun.

Beim Durchlesen ist mir so eingefallen:
Was passiert mit den Abständen, wenn Du das Kerning von „Metrisch“ auf „Optisch“ umstellst ?

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Hallo Bernd,

Antwort auf:

Dass ich den Fehler bislang nicht kenne, kann möglicherweise damit zu tun haben, dass ich praktisch NIE mit Blocksatz arbeite.

Ja, Blocksatz ist eine zwingende Voraussetzung für diesen "Ausgleichsfehler".
Im Flattersatz (z.B. Tabellen oder Zitate) ist nach meinen Beobachtungen alles in Ordnung.

Viele Grüße
Martin

Hallo Peter,

vielen Dank für Deinen Tipp.

Antwort auf:

Was passiert mit den Abständen, wenn Du das Kerning von „Metrisch“ auf „Optisch“ umstellst?

Der Fehler "springt" an andere Stellen.

Aber eins scheint etwas anders zu sein gegenüber "Metrisch".
Bei "Metrisch" habe ich oft ein Loch innerhalb eines Worts.
Bei "Optisch" gibt es die Löcher, aber auch ungleichmäßge Sperrungen: siehe Beispiel.

Wenn's keine ärgerlichen Fehler wären, die beim Leser zu Missverständnissen und Stirnrunzeln führen, könnte man von einer unterschiedlichen Ästhetik der Zufallsgestaltung sprechen. ;-)

Habe inzwischen auf der Suche nach dem einen Knopf, nach der einen entscheidenden Einstellung praktisch alle Schalter (der Zeichen- und Absatzformate) durch, ohne den Fehler vermieden zu haben.

Es gibt Stimmen, die sagen, es könnte mit einem bestimmten (noch herauszufindenden) Sonderzeichen auf der Doppelseite zusammenhängen.
Das erinnert an das einfache untere Anführungszeichen und das cyrillische kleine Kappa als Auslöser für das Verschwinden von Fußnoten(text) beim DOC-Import.

Viele Grüße
Martin

Hallo Martin,

mir ist nicht bekannt, dass von Seiten der Entwickler der Fehler angegangen wird. Adobe schweigt dazu. Falls sich das mal ändern sollte, werden sich sicherlich Adobe-Mitarbeiter in den von Dir geposteten Threads im amerikanischen InDesign-Forum zu Wort melden.

Das ist äußerst frustrierend und nicht nur Du befindest Dich am Rande der Verzweiflung.

Die Option 3, die Du nennst:

Zitat

3. Korrekur der Fehler in InDesign (manchmal ganz brutal durch Zuweisung des normalen Adobe Absatzsetzers und Umkehrung der Reihenfolge der hebräischen Zeichen per Skript) und Export von Einzelseiten.

wäre die einzige Möglichkeit, die ich im Moment für Dich sehe.

Aber das ist ja kein echter Workaround, wenn es darum gehen sollte die Inhalte in anderer Form als in einem Druckwerk zu nutzen. Und selbst da ist das eigentlich "schwachsinnig", da sich die üblichen Suchen/Ersetzen-Funktionalitäten in InDesign nicht mehr anwenden lassen.

Du bräuchtest also wirklich eine alte ME-Version, um erflogreich weiterzukommen. Aber wie kommt man an diese? Unabhängig von der Frage, ob noch die Hardware und das richtige Betriebssystem verfügbar ist, um die zu fahren?

Eine Idee aus Verzweiflung geboren, ziemlich umständlich, nicht getestet und dürfte unerträglich lange Abarbeitungszeiten haben:

Die Position jedes Characters innerhalb eines Words auf seinen Abstand hin zum nächsten überprüfen, um dann mit Unterschneidung einzugreifen.
*****
Mit herzlichem Gruß,
Uwe Laubender

Hallo Uwe,

Antwort auf:

Eine Idee aus Verzweiflung geboren, ziemlich umständlich, nicht getestet und dürfte unerträglich lange Abarbeitungszeiten haben:
Die Position jedes Characters innerhalb eines Words auf seinen Abstand hin zum nächsten überprüfen, um dann mit Unterschneidung einzugreifen.

Das ist eine interessante Idee, auch wenn ich ihr praktisch nicht viel Nutzen einräume. Denn nach meinen Beobachtungen reicht manchmal eine einfache typographische Änderung (mit geringsten Werten, also eine Änderung, die lediglich eine neue Umbruchberechnung im Absatz ausführt), um den entdeckten Fehler kurzfristig zu korrigieren.
So eine Korrektur hat oft aber eher einen labilen, vorübergehenden Charakter: sie bietet keine Sicherheit oder Garantie, dass der Fehler später, wenn man gerade nicht hinschaut, wieder eintritt.

Immerhin könnte Dein Analysevorschlag beim Finden der Fehler unterstützen.
Man müsste mal prüfen, ob sich diese unerwünschten Spatien ausmessen lassen.
Diese kännte man dann z.B. mit bedingtem Text zum besseren Auffinden per Sichtkontrolle markieren.
Die Sache ist so "verrückt", dass Mathematik hier möglicherweise weiterhelfen könnte. ;-)


Eine andere Brutalo-Methode, die ich zeitweise mit gewissem Erfolg anwandte (die Verzweiflung war groß), hatte ich oben zurückgehalten, um mich nicht einem Gelächter auszusetzen:
die Zerhackstückelung eines Absatzes in mehrere Absatzeinheiten jeweils ohne oder mit Hebräisch (Umkehrung der Schreibrichtung).

Wenn also z.B. in einem 10-zeiligen Absatz in der 4. Zeile eine hebräische Phrase stand, dann zerlegte ich diesen einen Absatz in drei Teil-Absätze:
1. Zeilen 1-3: zugewiesenes AF mit normalem Adobe-Absatzsetzer (ggf. mit Einzug beginnend) und "fully justified" (Blocksatz auch der letzten Zeile);
2. Zeile 4: zugewiesenes AF mit Globalem Absatzsetzer, stumpf beginnend und ebenfalls "fully justified";
3. Zeile 5-10: wie 1. mit normalem Adobe-Absatzsetzer, stumpf beginnend und Blocksatz mit letzter Zeile linksbündig.

Damit konnte ich die problematische(n) Zeile(n) isolieren.
Aber es ist nicht nur die Struktur dahin.
Es kommt auch häufig vor, dass die problematische Stelle sich gerade in der isolierten Zeile/den isolierten Zeilen mit dem Globalem Absatzsetzer befindet. Und dann ist zwar der Fehlerbereich eingeschränkt, aber der Fehler noch nicht behoben.

Das Tränen- und Schweißtreibende ist der Wahnsinnsaufwand bei der manuellen Sichtkontrolle: immer wieder, es gibt keine Sicherheiten und keinen Verlass, dass eine gute Stelle eine gute Stelle bleibt, die man einfach abhaken könnte.
Deswegen nach intensiver Kontrolle einer Einzelseite ein Einzelseiten-PDF erstellen (Gutes eingefroren).

Viele Grüße
Martin

Hallo Martin,

das sieht wirklich spannend aus. Ich würde es mir gerne mal anschauen, ohne Dir allzuviel Hoffnung machen zu wollen. Gibt es eine Möglichkeit, dass Du zwei, drei Seiten separierst und zugänglich machst?

Viele Grüße
Uli

Hallo Uli,

Harbs von InTools hat auch Interesse an einem Beispieldokument angemeldet.
Ich werde so ein Dokument vorbereiten und auch hier bereitstellen.

Möglicherweise schaffe ich dies erst morgen.

Viele Grüße
Martin

Hallo Martin,
danke, dass Du das bereitstellen möchtest.

Ich glaube, da habe ich heute Vormittag 'was angestoßen als ich andernorts an geeigneter Stelle den Link zu diesem Thread hier postete.

( Also das muss ich dann auf meine Kappe nehmen, wenn Du von Anfragen nach Probematerial überhäuft wirst ;-) )
*****
Mit herzlichem Gruß,
Uwe Laubender

Hallo Martin,

falls nicht zu viele Hebräische Wörter vorkommen, wäre es noch einen Versuch wert, die hebräischen Begriffe als verankerte Objekte im Fließtext mitlaufen zu lassen, oder auf die „Brutale Art“ als Bild.

Nachtrag: Oder die hebräischen Begriffe in Textpfade umwandeln ?

„Du Armer“ ;-)

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Hallo Uwe,

Antwort auf:

( Also das muss ich dann auf meine Kappe nehmen, wenn Du von Anfragen nach Probematerial überhäuft wirst ;-) )

Ne, ne, ne ...
Hab gestern den Support von WorldTools wg. dem Problem angeschrieben.
Und jetzt bin ich froh, dass sich Harbs interessiert zeigt.
Hätte aber eher eine Reaktion erwartet wie "Problem bekannt, keine Chance; mal sehn was die Zukunft bringt."

Bin heute Nachmittag mit der Zeit etwas knapp bemessen.

Das mit dem Testdokument ist deswegen etwas aufwendiger, weil ich zunächst beim Kunden eine entsprechende Erlaubnis zur Weitergabe der Daten einholen möchte und dann einen Ausschnitt wähle, der keine direkten Rückschlüsse auf den Urheber zuläßt. Ferner muss ich darauf achten, dass mir nicht noch ein Fremdplugin wie InDihyph in das Musterdokument reinpfuscht.

Viele Grüße
Martin

Hallo Peter,

beide gut gemeinten Vorschläge kommen nicht in Frage.

Zum einen geht damit die mit dem Globalen Absatzsetzer verbundene Funktionalität (z.B. Zeilenumbruch innerhalb einer hebräischen Phrase) verloren.

Zum anderen ist das mit ähnlich viel oder noch mehr Aufwand wie die Umkehrung der Reihenfolge ausgewählter hebräischen Zeichen per Skript und die Zuweisung des normalen Adobe Absatzsetzers verbunden.

Zum dritten besteht die Gefahr des Qualitätsverlusts (Textpfade: Unterschneidungen gehen verloren - was passiert mit Vokalisierungszeichen unter den Buchstaben? - Textpfade erweitern die Kontur geringfügig; verankerte Objekte: Ausrichtung an den Kanten links und rechts? Reaktion auf Umbruchverschiebungen ...).

Viele Grüße
Martin

Hallo Martin,

für ein Beispieldokument würde ich mich auch interessieren. Ich hänge mal ein Foto einer der Stellen an, an denen ich Hebräisch benutzt habe. Orignal aus CS4 oder 6, gerade in CC2015.4 das erste Foto erstellt. Betriebssystem Win10; Schriftarten: Minion Pro und FrankRuehl (für das Hebräische)

Ich kann in meinem Foto deine Probleme nicht erkennen (oder ich bin betriebsblind), optisch fallen mir keine außergewöhnliche, nicht gewollte Sperrungen auf – gestehe aber, dass ich nicht regelkonform vorgegangen bin: Im Absatz gilt der Adobe-Setzer, nicht der Global-Absatzsetzer, und man sieht (hebraeisch_jkob.png) die hebräischen Buchstaben (die vom Autor als korrekt gesetzt freigegeben wurden), die ich mit zwei Macros, r2l und l2r, erstellt und mit gleichlautenden Zeichenformaten versehen habe. D.h. die Cursorrichtung ist herkömmlich von links nach rechts, (nur) die Leserichtung des Hebräischen ist von rechts nach links. Solange ich nur eine Version für den Druck herstelle, könnte ich damit leben.

Ich weiß, das ist eine Krücke, die die Textkonformität und die Möglichkeiten der Weiterverarbeitung des Textes ausschließt – das 2. Foto (hebraeisch_html_jkob.png) zeigt, dass das Hebräische falsch nach HTML gebracht wird. Deswegen bin ich an einer Lösung interessiert, die es mir auch ermöglicht, Hebräisch korrekt und optisch ansprechend zu setzen, damit es nicht nur im Printprodukt, sondern in anderen Produkten passt.

Viele Grüße
Jörn
Viele Grüße

Jörn aka Jabadabadu

——————————————————————————————————————————
Dr. Jörn Kobes @ www.computus-druck.com
Win 8/Win 10 — Creative Suite 2 – CC 2022
——————————————————————————————————————————

Hallo Jörn,

Antwort auf:

Ich kann in meinem Foto deine Probleme nicht erkennen (oder ich bin betriebsblind), optisch fallen mir keine außergewöhnliche, nicht gewollte Sperrungen auf
(...)
Im Absatz gilt der Adobe-Setzer, nicht der Global-Absatzsetzer

Das ist ja der Kern meiner Botschaft / Beanstandung:
Solche Probleme sind ganz klar mit dem Globalen Absatzsetzer (im Zusammenhang mit Blocksatz) verbunden.
Mit Verwendung des normalen Adobe Absatzsetzers verschwinden diese Probleme (aber auch die Funktionalität der gemischten Schreibung Links-Rechts und Rechts-Links).

Viele Grüße
Martin

Ok, jetzt ein weiteres Foto – der Globale Absatzsetzer ist in diesem Absatz eingeschaltet, das darfst du mir glauben.

Ich sehe auch hier keine Unterschiede. Vielleicht warten wir dein Beispieldokument mit mehr Hebräisch einfach mal ab.
Viele Grüße

Jörn aka Jabadabadu

——————————————————————————————————————————
Dr. Jörn Kobes @ www.computus-druck.com
Win 8/Win 10 — Creative Suite 2 – CC 2022
——————————————————————————————————————————

Hallo Martin,

ich geb mir alle Mühe das Problem auf dem Mac bei mir nachzustellen - ohne Erfolg.

Meine Beispieldateien zum Download:

https://www.dropbox.com/...-hebraeisch.zip?dl=0

IDCS6, gesetzt mit dem globalen Absatzsetzer.

Rote Typo = Systemschrift Arial Hebrew, TrueType
Blaue Typo = Adobe Hebrew, OpenType

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Hallo Jörn,

auch wenn es nun ein wenig vom Ursprungsthema abweicht …

Zitat

… dass das Hebräische falsch nach HTML gebracht wird. Deswegen bin ich an einer Lösung interessiert, …

Ich habe gerade mal meine oben genannte Beispieldatei (zum Download) aus IDCS6 als HTML exportiert. In Safari und Firefox schaut das Ergebnis perfekt aus. Vielleicht probierst Du mal die Typo „Adobe Hebrew“, die müsste Dir auf dem PC auch zur Verfügung stehen.

Da ich schon länger keine Webseiten mehr gestalte, bin ich jedoch aus dem Thema ziemlich raus.

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Hallo Peter,

das Problem ist die falsche Schreibrichtung – der Font ist hier m. W. nicht so sehr das Problem. Denn auch mit Unicode-Fonts oder OTF wird die Schreibrichtung R2L nicht mehr eingehalten.
Viele Grüße

Jörn aka Jabadabadu

——————————————————————————————————————————
Dr. Jörn Kobes @ www.computus-druck.com
Win 8/Win 10 — Creative Suite 2 – CC 2022
——————————————————————————————————————————

Hallo Jörn,

die Schreibrichtung bleibt erhalten (Screenshot). Links Safari, rechts PDF.

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Hallo Jörn,

das Verflixte ist, dass der Fehler nicht zuverlässig, berechen- oder erwartbar und auch nicht in jedem Absatz, der mit dem Globalen Absatzsetzer ausgezeichnet ist, auftaucht. Bislang ist es mir auch nicht gelungen, eine Situation einzurichten, die diesen Fehler für mich und für andere reproduzierbar provoziert.

Jetzt wollte ich ein paar Seiten, auf welchen der Fehler im Originaldokument mehrfach aufgetreten war, zur Analyse bereitstellen und muss hinnehmen, dass mit der Reduzierung des Dokuments auf die problematischen Seiten die Probleme größtenteils verschwinden oder nicht mehr auftauchen. Beeinflusst die nicht-typographische Umgebung (Position, andere Seitenobjekte, Umfang, andere Textabschnitte) den Fehler?

Die Beispieldatei ist deswegen auf eine Seite mit drei leider weniger starken Ausprägungen (aber denoch erkennbar) reduziert.
Die vorbereiteten Daten: WorldReady Composer Test.zip

Darin enthalten:
WorldReady Composer Test.indd (InDesign CS6 Datei)
WorldReady Composer Test.pdf (exportierte PDF-Datei)
WorldReady Composer Test.jpg (Bildschirmfoto)

Die problematischen Stellen sind im Bildschirmfoto markiert.


Im Dokument wurden die Stempel Garamond LT Std als Grundschrift und SBL Hebrew für Hebräisch vewendet.

SBL Hebrew kann kostenlos heruntergeladen werden von https://www.sbl-site.org/...Fonts_SBLHebrew.aspx
Die Grundschrift (Stempel Garamond LT Std) kann ich leider nicht zur Verfügung stellen. Ein Versuch, in der Beispieldatei die Grundschrift durch die verbreitete Minion Pro schlug fehl: alle Fehler waren verschwunden und ließen sich nicht wieder hervorlocken.

Auf die Herstellung einer vertretbaren Beispieldatei habe ich nun mehr als zwei Stunden verbraucht und muss an diesem Punkt abbrechen. Vielleicht gelingt es mir in ruhigeren Zeiten im Hinblick auf den Fehler aussagekräftigere Daten zusammenzustellen. Entsprechende Beispiele werde ich in den nächsten Tagen sammeln.

Viele Grüße
Martin

Hallo Martin,

ich habe Deine Beispieldatei mal geprüft. Die von Dir genannte hebräische Typo habe ich installiert. Von der Stempel Garamond habe ich nur die PostScript-Version.

Der Text wurde bei mir komplett rot durchgestrichen dargestellt. Hast Du auf das Dokument das Script „ShowHideLocalFormatting.js“ angewandt ? Erst nachdem ich Schriftersetzung mit Neudefinierung der Formate durchgeführt habe, verschwanden diese roten Linien.

Dennoch kann ich exakt an denselben Stellen, die von Dir im Screenshot rot markierten Stellen ausmachen.

Das Ersetzen Deiner hebräischen Typo durch die Adobe Hebrew bringt auch keine Veränderung.

Was mir auffällt ist, dass Du in Deinen Formatierungen viele „krumme“ Werte hast, bis auf die 3. Nachkommastelle. Die habe ich alle mal auf „glatte“ Werte gesetzt.
Auch die Schrift-Skalierung von 94% horizontal und vertikal im Bodytext habe ich mal auf 100% gesetzt, dafür die Schriftgröße entsprechend reduziert. Ich hätte eher die hebräische Typo an den Bodytext angepasst, aber das ist Geschmackssache.

Summa summarum: Ich finde keine Stellschraube mit der das Auftreten ungewollten Kernings vermieden werden kann. Bei den betroffenen Stellen werden noch nicht mal abweichende Kerning-Werte angezeigt. Daraus schließe ich, dass es nicht wirklich ein typografisches Problem ist, sondern ein Rendering-Problem.

Beste Ergebnisse, wenn auch nicht fehlerfrei, erhalte ich dennoch mit dem optischen Kerning.

Nachtrag: Nenne das Layoutprogramm im Impressum und schicke ein gedrucktes Exemplar an Adobe ;-)

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Hallo Peter,

Antwort auf:

Der Text wurde bei mir komplett rot durchgestrichen dargestellt. Hast Du auf das Dokument das Script „ShowHideLocalFormatting.js“ angewandt ?

Ja.

Antwort auf:

Dennoch kann ich exakt an denselben Stellen, die von Dir im Screenshot rot markierten Stellen ausmachen.

Prima.

Antwort auf:

Das Ersetzen Deiner hebräischen Typo durch die Adobe Hebrew bringt auch keine Veränderung.

Es ist unabhängig von der Schrift für Hebräisch.
Es ist unabhängig von Hebräisch überhaupt.
Der Fehler tritt auch in Absätzen, die ohne Hebräisch mit dem Globalen Absatzsetzer formatiert sind, auf. Deswegen hatte ich mir ein bißchen damit beholfen, dass der Globale Absatzsetzer nur dort verwendet wird, wo er auch tatsächlich benötigt wird. Deswegen auch die Formatgruppe "Heb (e)", deren Basis-AF auf dem Basis-AF aus der Formatgruppe "e" basiert mit dem einen Unterschied: Globaler Absatzsetzer.

Antwort auf:

Was mir auffällt ist, dass Du in Deinen Formatierungen viele „krumme“ Werte hast, bis auf die 3. Nachkommastelle. Die habe ich alle mal auf „glatte“ Werte gesetzt.

Das liegt daran, dass ich mit Didot-Punkt arbeite, da der Kunde seine Satzanweisungen in Didot-Punkt erteilt.

Antwort auf:

Auch die Schrift-Skalierung von 94% horizontal und vertikal im Bodytext habe ich mal auf 100% gesetzt, dafür die Schriftgröße entsprechend reduziert. Ich hätte eher die hebräische Typo an den Bodytext angepasst, aber das ist Geschmackssache.

Das hat Gründe, die ich hier nicht weiter ausführen möchte. Nur so viel: Es hat mit dem Verhältnis von Schriftgröße der Stempel Garamond zu Zeilenabstand zu tun und ist für mich so einfacher zu organisieren als die umgerechnete Schriftgröße mit x Nachkommastellen zu verwenden.
Hat auf den Fehler aber keinen Einfluss.
Der Fehler tritt z.B. in Minion auch mit 100% auf.

Antwort auf:

Summa summarum: Ich finde keine Stellschraube mit der das Auftreten ungewollten Kernings vermieden werden kann. Bei den betroffenen Stellen werden noch nicht mal abweichende Kerning-Werte angezeigt. Daraus schließe ich, dass es nicht wirklich ein typografisches Problem ist, sondern ein Rendering-Problem.

Ja, den Verdacht habe ich auch.
Aber wie könnte man hier dagegen wirken?

Antwort auf:

Beste Ergebnisse, wenn auch nicht fehlerfrei, erhalte ich dennoch mit dem optischen Kerning.

Täuche Dich nicht. Wenn der Fehler hier mit Kerning optisch weniger stark in Erscheinung tritt, so tritt er an anderen Stellen mit Kerning optisch erst in Aktion.


Ein weiteres frustrierendes Beispiel: Vergleich InDesign Layout - PDF.

In InDesign (links) ist die Darstellung vor und nach dem Export der Seite ok.
Der Fehler zeigt sich erst in Acrobat (rechts). :-((

Also hilft es nur, die PDF-Datei, die zum Druck geht, intensiv zu kontrollieren.
Immer wieder Einzelseiten korrigieren und exportieren und in der PDF-Datei austauschen ...

Viele Grüße
Martin

Hallo Martin,

ich habe die normale LT verwendet (nicht die Standard) und konnte das Problem auch bei mir nachvollziehen. Die ganze Sache ist völlig inkonsistent. Nun möchte ich ungern falsche Fährten legen, doch nach etlichen Versuchen habe ich zumindest bei der vorliegenden Einzelseite den Eindruck, dass sich ein besseres Bild ergibt, wenn die Schriftgröße auf 10pt geändert wird. Die Annäherung an den vorherigen Grad könnte dann über die Skalierung nachjustiert werden. Ob sich dann wieder das alte Bild ergibt müsstest Du mit einer separaten Datei testen.

Hallo Uli,

danke für Dein Testen.

Antwort auf:

Nun möchte ich ungern falsche Fährten legen, doch nach etlichen Versuchen habe ich zumindest bei der vorliegenden Einzelseite den Eindruck, dass sich ein besseres Bild ergibt, wenn die Schriftgröße auf 10pt geändert wird.

Das Problem ist unabhängig vom Schriftgrad und Skalierungsangaben.
Taucht in anderen Dokumenten mit anderen Schriften und anderen Größen und Skalierung bei 100% genauso auf.

Jeder typographische Eingriff kann eine Änderung bewirken, zum Positiven wie zum Negativen. Ein globaler Eingriff kann an der einen Stelle das Problem beheben, aber an einer anderen Stelle frisch provozieren.

Viele Grüße
Martin

@Uli:

Oder meinst Du, der Fehler könnte durch meine andere Grundeinstellung bei der Punkt-Größe verursacht sein?

Dem widersprechen die entsprechenden Beiträge im Adobe InDesign-Forum und Informationen, die ich von einem Schriftsetzer aus Israel habe, mit dem ich vor ca. einem halben Jahr ein von uns beiden eingesetztes Plugin als möglichen Verursacher diskutiert hatte. Das Ergebnis war damals negativ (das Plugin ist nicht schuld).

Viele Grüße
Martin

Hallo Martin,

ich habe mir interessehalber auch dein Dokument runtergeladen und reingeschaut. Auch bei mir tritt dieser Fehler auf.
Das einzige, was mir dazu einfällt scheitert wohl an der Vielzahl der hebräischen Stellen: die hebräischen Zeichen rauskopieren in einen eigenen Rahmen, diesen an den Text anpassen und wieder an die Stelle reinkopieren.
Dann könnte der hebräische Text seinen globalen Setzer haben und der normale Text, der dann ja ohne hebräische wäre, den Adobe-Setzer.
Wenn jetzt aber 5000 hebräische Stellen im Text sind, ist das auch kein Spaß. Oder könnte man da ein Script basteln?

Gruß, Michael

Hallo Martin,

ich hatte vergessen zu erwähnen, dass ich mit IDCS6 gestestet habe.
Habe eben nochmal die aktuellste Version von IDCC2015 probiert – exakt dasselbe Ergebniss.

Zitat

Ja, den Verdacht habe ich auch.
Aber wie könnte man hier dagegen wirken?

Indem man den Fehler Adobe meldet. Habe aber die Befürchtung, dass die weniger typografisch geschulten Augen der Entwickler die meisten Fehlstellen gar nicht bemerken werden.

Wäre Quark XPress eine Alternative ? Ich habe mich ja schon vor ca. 10 Jahren davon verabschiedet und kann es nicht mehr testen.

Zitat

Ein weiteres frustrierendes Beispiel: Vergleich InDesign Layout - PDF.

„Auweia“ ;-)

Zitat

Oder meinst Du, der Fehler könnte durch meine andere Grundeinstellung bei der Punkt-Größe verursacht sein?

Das war mir auch aufgefallen – eine Änderung auf PostScript(72 Pt/Zoll) ändert überhaupt nichts.

Du bist mit diesem Job wirklich nicht zu beneiden – kann nur hoffen, dass Dein Auftraggeber ein gewisses Verständnis aufbringt.

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Hallo Martin,

nein, ich meinte schon die normale Schriftgröße.

Ich hatte mit CS6 die Schrift auf 10pt gesetzt und gesehen, dass die Fehler an den mir aufgefallenen Stellen verschwunden waren. Um weiter zu probieren müssten mehrere Seiten vorliegen. Aber vielleicht war das auch Zufall und zu schön, um wahr zu sein. In jedem Fall ist das ein dickes Ding – Schande über Adobe, dass sie das einfach auf sich beruhen lassen.

Viele Grüße
Uli

Hallo Michael,

Antwort auf:

Dann könnte der hebräische Text seinen globalen Setzer haben und der normale Text, der dann ja ohne hebräische wäre, den Adobe-Setzer.
Wenn jetzt aber 5000 hebräische Stellen im Text sind, ist das auch kein Spaß. Oder könnte man da ein Script basteln?

Eine ähnliche Idee hatte auch Peter.
Ist nicht praktikabel, zumal es auch Zeilenumbrüche innerhalb von hebräischen Phrasen geben kann.

Da wäre die Lösung, ohne den Globalen Absatzsetzer zu arbeiten und die Reihenfolge der hebr. Zeichen umzukehren und beim Zeilenumbruch Textteile umzustellen, vorzuziehen.

Viele Grüße
Martin

Antwort auf:

Indem man den Fehler Adobe meldet. Habe aber die Befürchtung, dass die weniger typografisch geschulten Augen der Entwickler die meisten Fehlstellen gar nicht bemerken werden.

Vergiss es. :-(
Der Fehler dürfte schon seit Jahren bekannt sein.
Ist selbst in dem echten Nachfolger von ID ME, CC Hebrew/English, zu finden.
Der Markt ist zu klein, der Aufschrei zu leise.

Antwort auf:

Wäre Quark XPress eine Alternative ? Ich habe mich ja schon vor ca. 10 Jahren davon verabschiedet und kann es nicht mehr testen.

Wußte nicht, dass Quark rechts-links unterstützt.
Aber das wäre wahrscheinlich eher was für die Generation nach mir.
Lieber plage ich mich mit bekannten "Gegnern". ;-)

Dann eben so wie vor 20/25 Jahren in Pagemaker:
Verzicht auf den globalen Absatzsetzer, keine rechts-links Unterstützung, sondern von Hand alle hebräischen Phrasen umstellen (und Vokalisierungen händisch nachjustieren).

Viele Grüße
Martin

Hallo Martin,

ich glaube wir lassen Dich jetzt besser in Ruhe, damit Du Dich auf Deine Arbeit konzentrieren kannst. Du kennst ja die „Stellschrauben“ an denen man ansetzen kann.

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Hallo Martin,

eine letzte Info noch …

Mit QXP gäbe es eine Möglichkeit mit der „Arabic XT für QuarkXPress“ von CoDesCo, mit der auch Hebräisch machbar ist, siehe hier:

http://www.xpress-upgrade.com/...ress-2015-verfuegbar

Wenn Du aber noch nie mit QXP gearbeitet hast dürfte eine Umstellung (evtl. mit ID2Q) zu spät sein.

Vielleicht für künftige Projekte mal im Auge behalten.

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Hallo Peter,

Antwort auf:

Habe eben nochmal die aktuellste Version von IDCC2015 probiert – exakt dasselbe Ergebniss.

Hast Du die INDD in CC 2015 geöffnet oder eine IDML?
Eine IDML würde möglicherweise Fehler, die über die INDD hochkonvertiert/-transportiert werden, vermeiden.

Aber ich geb da keinen Pfifferling mehr drauf.


P.S.: Habe aus der ID ME Ecke (InDesign CS 5.5 ME) zwitschern hören, daß der Fehler sich dort nicht reproduzieren lassen will. Damit bestätigt sich eine Vermutung, die ich weiter oben geäußert habe.


Vielen Dank für die rege Beteiligung bei der Analyse und Diskussion des Fehlers und der Unterstützung mit Lösungsvorschlägen.

Viele Grüße
Martin

Hallo Martin,

Zitat

Hast Du die INDD in CC 2015 geöffnet oder eine IDML?

Ich hatte Deine Testdatei direkt in IDCC2015 geöffnet.

Soeben habe ich noch eine „.idml“-Datei aus IDCS6 erstellt und in IDCC2015 geöffnet. Trauriges Ergebnis, heute gibt es keine Pfifferlinge – exakt diesselben Fehlerstellen.

Was meine Beteiligung anbelangt – gerne geschehen. Ich denke immer – wenn mir das passieren würde, da wäre ich ebenfalls froh um jede Hilfe.

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Antwort auf:

Soeben habe ich noch eine „.idml“-Datei aus IDCS6 erstellt und in IDCC2015 geöffnet. Trauriges Ergebnis, heute gibt es keine Pfifferlinge – exakt diesselben Fehlerstellen.

Versuch's mal mit CS4 ;-)
Da kannst Du den Teufel was typoographisch manipulieren wie Du wills: der Fehler lässt sich in der Beispieldatei in CS4 nicht reproduzieren!

Oben war ich ungenau:

Zitat

Habe aus der ID ME Ecke (InDesign CS 5.5 ME) zwitschern hören, daß der Fehler sich dort nicht reproduzieren lassen will.

Tatsächlich zwitscherte es aus dieser Ecke, dass sich der Fehler in CS5.5 und CS5.5 ME nicht reproduzieren ließe.

Das habe ich nun zu einem Anlass für einen Test in InDesign CS4 genommen und sehe spontan ein Ergebnis wie ich es mir wünsche und heute früh noch nicht habe träumen lassen: Leerraum nur dort, wo er vorgesehen ist und weder Sperrungen noch unerwünschte Spatien.

Werde nun mit dem Umbruch eines weniger umfangreichen Büchleins (200 Seiten, mit häufiger Verwendung des Globalen Absatzsetzers), den ich vorhin in CS6 fertiggestellt habe (und wo ich an einzelnen Stellen den Fehler im Augenwinkel erkannte) runter zu CS4 umsiedeln und ganz scharf drauf kucken, was mich dort erwartet.
Vielleicht die Lösung dieser langen Diskussion?

Viele Grüße
Martin

Hallo Martin,

IDCS4 und CS5.5 habe ich nicht mehr installiert, die CDs sind zur Not jedoch noch vorhanden. Mir reicht es jeweils 4 Versionen (teilweise auch mehr) und deren Eigenheiten auf dem Rechner zu haben, und bald wird es ja noch eine Version mehr. Irgendwann wird es dann unüberschaubar.

Ich drücke Dir die Daumen, dass es mit IDCS4 klappt !
Alles andere wäre ein elendes Gewurschtel, wenn Du dann auch noch seitenweise im PDF editieren müsstest. Vielleicht gibt es ja heute doch noch Pifferlinge ;-)

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Antwort auf [ Martin Fischer ]

Tatsächlich zwitscherte es aus dieser Ecke, dass sich der Fehler in CS5.5 und CS5.5 ME nicht reproduzieren ließe.

Hallo miteinander,

jetzt bin ich mir gerade nicht sicher, ob ich der Zwitscherer oder die Ecke bin, aber jedenfalls habe ich die Indesign ME bis zurück zur Version CS3 noch hier installiert. Ich hab' schon immer gesagt, dass es seit CS4 nichts Upgradewertes mehr (für mich) gegeben hat... aber echte Gründe für ein Downgrade sind neu ;-)

Vielleicht für alle interessant: ich habe mal einen direkten Vergleich zwischen Martins Test-PDF und der von mir mit CS5.5 erstellten PDF als animierte GIF gebastelt, zu betrachten hier:

http://www.meissner-dokuteam.de/...dyComposer_test.html

Da sieht man sehr schön, wie eigentlich mehr oder weniger die ganze Zeile bis hin zur "Bruchstelle" betroffen ist, und auch der Zeilenabstand ist manchmal involviert. Das benimmt sich fast wie eine Skalierung, mal proportional, mal nicht. Seltsam, das…

Grüße,
Bernd
---------------
cavete fenestras et nubes!

Hoi Bernd,

Antwort auf:

aber echte Gründe für ein Downgrade sind neu

Bin mit dem 200 Seiten Buch nach CS4 runtergesiedelt.
Und war erst mal von der Geschwindigkeit von CS4 begeistert. ;-)

Habe alle Textabschnitte per Skript neu umbrechen lassen und anschließend eine aus CS6 exportierte PDF-Datei auf einer Ebene im Hintergrund platziert.

Zunächst war ich von der Tatsache, dass sich der Umbruch nur an wenigen Stellen verschoben hat, positiv überrascht.

So konnte ich nun gezielt die Stellen in Absätzen mit dem Globalen Absatzsetzer vergleichen: Der blaue Text aus CS4 überlagert den schwarzen Text aus der PDF-Datei aus CS6.

CS4-Textebene ausgeblendet und nur die aus CS6 exportierte PDF-Datei aktiv ist leicht zu erkennen, woher die Abweichung der Überlagerung resultiert:
1. CS6 macht’s falsch
2. CS4 macht’s richtig

Es handelt sich hier nicht um einen einzelnen Sonderfall, sondern von diesem Vergleich per Überlagerung könnte ich noch viele Beispiele einstellen.

Nicht jede Verschiebung ist auf den Fehler zurückzuführen.
Manchmal ist nur die Silbentrennung anders - und damit der Zeilenfall.

Aber überall dort, wo sich die Verschiebung der Überlagerung auf eine falsche Spationierung zurückführen lässt, hat CS6 versagt.

Für mich ist das jetzt ein schwerwiegender Grund, gemischtsprachige Dokumente mit dem Globalen Absatzsetzer nicht in CS6 und nicht in CC 2015, sondern in CS4 zu setzen.

Mal sehn, was mir dabei aus CS6 fehlen wird. ;-)

Vielleicht die Spaltenspanne?
Wenn die mal nicht eine versteckte Ursache für diesen Fehler in CS6 ist.
Der traue ich so was glatt zu: Wer den Fußnotenapparat zerhackstückelt, der sorgt auch für falsche Spationierungen, die keiner mehr loskriegt. ;-)


Uff, jetzt bin ich richtig erleichtert und sehe dem, was da kommen mag, entspannt entgegen.

Viele Grüße
Martin

Antwort auf [ Martin Fischer ]

Mal sehn, was mir dabei aus CS6 fehlen wird. ;-)

Vielleicht die Spaltenspanne?

Hallo Martin,

die gibt's zur Not in CS5.5 auch schon.

Antwort auf [ Martin Fischer ]

Uff, jetzt bin ich richtig erleichtert und sehe dem, was da kommen mag, entspannt entgegen.

Das freut mich zu hören :-)

Schöne Grüße,
Bernd
---------------
cavete fenestras et nubes!

Hallo Martin,

ich bin erst jetzt dazu gekommen Deine CS6-Beispieldatei zu testen.
Alle benötigten Schriften sind bei mir vorhanden.

Ergebnisse:

1. CS4 v6.0.6 KEIN RENDERINGFEHLER IM LAYOUT
IDML aus CS6 geöffnet

2. CS5 v7.0.4 KEIN RENDERINGFEHLER IM LAYOUT
IDML aus CS6 geöffnet

3. CS5.5 v7.5.3 KEIN RENDERINGFEHLER IM LAYOUT
IDML aus CS6 geöffnet

4. CS6 v8.1.0 Renderingfehler im Layout
Original geöffnet
IDML aus CS6 geöffnet

5. CC v9.3.0 Renderingfehler im Layout
Original CS6 geöffnet
IDML aus CS6 geöffnet

6. CC 2014.2 Renderingfehler im Layout
Original CS6 geöffnet
IDML aus CS6 geöffnet

7. CC 2015.4 Renderingfehler im Layout
Original CS6 geöffnet
IDML aus CS6 geöffnet

Was mich etwas erschrocken hat, ist Dein Vergleich der einen Textstelle, die im Layout keinen Renderingfehler aufweist, aber dafür im exportierten PDF.

Das scheint mir ein zweiter Bug zu sein.
*****
Mit herzlichem Gruß,
Uwe Laubender

Hallo Martin,

Ich wage mal zu behaupten, dass das Problem gelöst ist !
…falls meine Testdatei bei Dir am Bildschirm ebenso aussieht wie bei mir.

Ich hatte weiter oben schon mal erwähnt

Zitat

ich geb mir alle Mühe das Problem auf dem Mac bei mir nachzustellen - ohne Erfolg.

Das hat mir irgendwie keine Ruhe gelassen.

Ich habe Deine Beispieldatei genommen, die Seite dupliziert und mich auf die Suche nach dem bzw. den Übeltätern zu machen.

Seite 32 zeigt Deine Originalseite, Seite 33 die modifizierte Seite.

Der Übeltäter ist das verborgene Zeichen auf Seite 32 in Form eines senkrechten blauen Striches, dessen Bedeutung mir gegenwärtig nicht bekannt ist. Wenn man dieses Zeichen entfernt und den Textrahmen einmal an einem Anfasser zieht und wieder auf die ursprüngliche Größe bringt, sind die Problemstellen verschwunden.

Dass der Text „Eng. 10“ am Ende der Zeile, dennoch unschön aussieht, liegt einfach an den Abstandsoptionen des Absatzformats. Vor der 1 entsteht – bei metrischem Kerning – ohnehin immer ein relativ großer Freiraum.

Wie gesagt, wenn meine Testdatei bei Dir am Bildschirm ebenso aussieht wie bei mir, dürfte einer Produktion mit CS6 nichts mehr im Wege stehen.

Link Testdatei:
https://www.dropbox.com/...t_Lenz.indd.zip?dl=0

Nachtrag: Ein PDF/X-Test schaut auf die Schnelle betrachtet gut aus.

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Hallo Peter,

super, dass Du weitergeforscht hast!
Ich bin begeistert!

Das Sonderzeichen u200B ist eines in InDesign vorkommenden Sonderzeichen:

SpecialCharacters.DISCRETIONARY_LINE_BREAK
( Bedingter Zeilenumbruch )

Wähle das Zeichen aus und lasse folgenden ExtendScript-Schnipsel laufen:

Code

alert(app.selection[0].contents); 
// Result: SpecialCharacters.DISCRETIONARY_LINE_BREAK 

Ich kann Deine Lösung nachvollziehen.
Habe auch folgenden Test gemacht:

1. Sonderzeichen u200B entfernt
2. IDML-Datei exportiert
3. IDML geöffnet
=> Umbruch hat sich geändert, das Rendering ist so wie es sein soll!
*****
Mit herzlichem Gruß,
Uwe Laubender

Hallo Peter,

wenn dem so wäre, dann wäre das gemein, denn der bedingte Zeilenumbruch bei den Spatien nach "/" wurde von mir als Teil der Lösung ersonnen - textdesign als Alternative zu einem GREP-Stil.

Dazu später mehr.
Bin gerade in der Wildnis. ;-)

Hab einstweilen Dank für Deine Beharrlichkeit.

Viele Grüße
Martin

Hallo Martin,
ob das Sonderzeichen u200B der einzige Grund für Deine Misere ist, sei noch dahingestellt.

Hier ein Fall aus dem amerikanischen InDesign-Forum, der noch ungeklärt ist und bei dem ich in den dort veröffentlichten Screenshots kein u200B erkennen konnte:

weird character spacing in paragraphs
indralk Jan 6, 2015 2:04 AM
https://forums.adobe.com/message/7068291#7068291
*****
Mit herzlichem Gruß,
Uwe Laubender

Hatte früher mal den geschützten Wortzwischenraum in Verdacht.

Viele Grüße
Martin

Hallo Zusammen,

nur nochmal zum Verständnis, weil ich mich oben nicht ganz eindeutig ausgedrückt habe.

Zitat

ich geb mir alle Mühe das Problem auf dem Mac bei mir nachzustellen - ohne Erfolg.

Das gesagte bezog sich auf eine neu erstellte Datei und eigenem Text. Nun ist klar, warum das misslingen musste. Damals hatte ich schon so ein vages Bauchgefühl, es könnte auch am Text bzw. Formatierung von Martin liegen.

@ Uwe
Danke für den Script-Schnipsel – funktioniert bei mir.
(Sonntag 6:33 Uhr, vermutlich nach dem Joggen, Duschen, Rasieren und Frühstück – Respekt ! )

Der Bedingte Zeilenumbruch (habe ihn offenbar schon länger nicht mehr verwendet) wird nicht in der Adobe-InDesign-Hilfe aufgeführt, habe aber auf meiner Festplatte eine PDF-Datei gefunden, die vermutlich alle verborgenen Zeichen (und mehr) enthält, mit Tastenkürzel, Text- und GREP-Suche. Aber ihr kennt die Datei sicher.
Download-Link:
http://www.absatzsetzer.de/downloads/Zeichen.pdf

Falls der Bedingte Zeilenumbruch, das einzige Verborgene Zeichen ist, das Probleme in CS6 und CC macht, bleibt es dennoch ein Bug. Dieser Fehler lässt sich aber eindeutig an Abobe weitervermitteln.

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Hallo Peter,

hier die Liste der SpecialCharacters so sie InDesign als Enumeratoren verwendet:
http://www.indesignjs.de/...ecialCharacters.html

Auch 'ne gute Quelle für SpecialCharacters:
http://www.indiscripts.com/...4-special-characters

Dort u.a. auch gelistet:
U+205F (MEDIUM MATHEMATICAL SPACE)
Allerdings hat dieser keinen Enumerator wie's ausschaut.

Optisch wird der als querliegender Winkelhaken mit Winkel oben rechts angezeigt (wie der "Forced Line Break", aber höher positioniert). Darunter ein Punkt wie bei einem Leerzeichen.

Wie erzeugen?
Über TEXT suchen/ersetzen mit beliebigem Suchstring.
Ersetzen mit: <205F>

Hier wird er u.a. angezeigt:
http://www.indiscripts.com/...-a-typeface/en01.png

( Heute morgen wurde ich gegen 5:45 unsanft von einem ausgiebigen Wolkenbruch geweckt. Hatte beinahe alle Fenster und die Terrassentür geöffnet, um die Innentemperatur in der Wohnung zu senken. Der Post ging also unrasiert, ungeduscht, ungejoggt und unkoffeiniert an HDS raus ;-) )
*****
Mit herzlichem Gruß,
Uwe Laubender

Hallo Uwe,

vielen Dank für die Quellen – das ist doch deutlich aufschlussreicher als die InDesign-Hilfe.

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Hallo Peter,

nun konnte ich die von Dir angegebene Situation testen.

In der Tat scheint das Vorhandensein / Löschen des Bedingten Zeilenumbruchs an dieser Stelle (wiederholbar) Einfluss zu nehmen auf die falsche Spationierung.

Aber ... lösch mal den Bedingten Zeilenumbruch an dieser Stelle und füge ihn an einer anderen Stelle (in derselben Zeile oder anderswo) ein.
Je nach Position des Bedingten Zeilenumbruchs wirst Du entweder gar keine Störung der Spationierung oder eine Störung an einer anderen Stelle als der bisherigen feststellen.

Lösche mal den Bedingten Zeilennumbruch und füge vor dem getrennten 'patron' einen optionalen Trennstrich zur Unterdrückung der Silbentrennung ein ... da ist der Fehlerteufel wieder: Bildschirmfoto (nicht an der ursprünglichen Stelle, aber dafür mit Metastasen an mehreren anderen Stellen).

Der Bedingte Zeilenumbruch kann ein Auslöser für den Fehler sein, muss es aber nicht. Vielmehr zähle ich ihn ebenso wie andere Veränderungen auf Zeichenebene (Hinzufügung oder Ergänzung von Zeichen) oder auf Formatierungsebene (Änderung typographischer Eigenschaften) zu einem potentiellen Auslöser.

Ein weiteres Gegenbeispiel: Bildschirmfoto.
Hier taucht der Fehler ohne den Bedingten Zeilenumbruch auf.

Testdaten für diese Seite: 16-07-31_WorldReadyComposer.zip
Darin ist ein Snippet enthalten, das bei mir in einem neuen Dokument als platzierter Inhalt den im Bildschirmfoto gezeigten Fehler nicht immer unmittelbar nach dem Platzieren darstellt. Aber man kann den Fehler durch Änderung der Formatierung und Hinzufügen/Löschen von Zeichen provozieren: eine Neuberechnung des Umbruchs im "labilen" Absatz kann den Fehler zur Erscheinung bringen oder ihn beseitigen.

Irgendwie habe ich das Gefühl, InDesign "weiß" insgeheim sehr wohl, was richtig ist/wäre, entscheidet sich aber beim Abwägen vieler Gesichtspunkte manchmal (in einem ungünstigen Moment) für das Falsche.
Die wunderschöne Animation, die Bernd oben veröffentlicht hat, zeigt im Wechsel vom PDF mit der richtigen Darstellung und dem mit der unerwünschten Spationierung, was in besonders schönen (und seltenen) Momenten in InDesign passiert: der Wechsel zwischen richtig und falsch.

In dem Beitrag aus dem InDesign-Forum, auf den Uwe oben verwiesen hat, ist zu lesen:

Zitat

We have just recently upgraded to CS6 from CS4 and its only since the upgrade we are seeing this issue.

Bei einem Buch mit hebräischen Stellen auf gut der Hälfte der Seiten, das ich letzte Woche in InDesign CS4 umbrochen habe, machte ich optimistisch stimmende Erfahrugnen: weder in InDesign noch im Protokollausdruck noch in der PDF-Datei waren die unerwünschten Spationierungen zu finden.

Aber auch nach dieser positiven Erfahrung in CS4 wiege ich mich hier nicht in absoluter Sicherheit. Ich erinnere mich nicht zuletzt wg. eines Wortspiels – "in Dimant (der Name des Autors) steckt Dynamit" – noch an einen Titel, den ich Anfang 2014 zunächst in CS6 zu setzen begonnen habe, dann vermutlich wg. dem Fehler nach CS4 umgesiedelt bin. Wenn mich die Erinnerung nicht täuscht, dann traten die unerwünschten Spationierungen damals nicht im Layout, sondern im (PostScript)-Laserausdruck auf - weswegen ich mir damals auch einen neuen Laserdrucker angeschafft hatte, auf dem der Fehler dann nicht mehr auftauchte.
Etwas unsicher bin ich, wie es sich damals mit dem Erzeugen der PDF-Dateien verhielt. Die PDF-Dateien selbst sahen m.W. noch in Ordnung aus. Aber auf dem bewährten HP-Laserjet 4250 dtnsl konnte der Spationierungsfehler auftauchen (auch aus der PDF), wenn viele Seiten auf einmal gedruckt wurden - Einzelseiten waren ok, weswegen ich damals auch einen möglichen PostScript-Fehler in Erwägung zog. Damals paarten sich zu den unerwünschten Spationierungen aber auch Überlappungen von Zeichen. Könnte deswegen auch eine ganz andere Ursache, als der hier diskutierte Fehler haben.


@Bernd: InDesign CS5 und CS5.5 waren und sind für mich wg. einem anderen leidigen Fehler – plötzlich leere Seite – für Mengensatz nicht tauglich.

Viele Grüße
Martin

Hallo Martin,

Zitat

Aber ... lösch mal den Bedingten Zeilenumbruch an dieser Stelle und füge ihn an einer anderen Stelle (in derselben Zeile oder anderswo) ein.
Je nach Position des Bedingten Zeilenumbruchs wirst Du entweder gar keine Störung der Spationierung oder eine Störung an einer anderen Stelle als der bisherigen feststellen.

Ist bei mir nachvollziehbar. Der Bedingte Zeilenumbruch bleibt aber ein potentielles Problem.

Zitat

Lösche mal den Bedingten Zeilennumbruch und füge vor dem getrennten 'patron' einen optionalen Trennstrich zur Unterdrückung der Silbentrennung ein ... da ist der Fehlerteufel wieder: Bildschirmfoto (nicht an der ursprünglichen Stelle, aber dafür mit Metastasen an mehreren anderen Stellen).

Ist bei mir nicht nachvollziehbar, auch nicht nach mehrmaligen Versuchen und Text-Redraw.

Zitat

…dann traten die unerwünschten Spationierungen damals nicht im Layout, sondern im (PostScript)-Laserausdruck auf…

Das mag auch damit zusammenhängen, ob der Laser-Drucker mit Original Adobe PostScript arbeitet bzw. mit einem Clone.

Deine Beispieldatei kann ich leider nicht öffnen „… ein für die Unterstützung notwendiges Zusatzmodul fehlt …“.

Nachtrag: Es liegt wohl an der Dateiendung ".idms" ?

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Hallo Martin,

jetzt habe ich es gerafft – die „.idms“-Datei ist das Snippet selbst (sorry heute ist Sonntag ;-)

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Hallo Martin,

Zitat

Darin ist ein Snippet enthalten, das bei mir in einem neuen Dokument als platzierter Inhalt den im Bildschirmfoto gezeigten Fehler nicht immer unmittelbar nach dem Platzieren darstellt. Aber man kann den Fehler durch Änderung der Formatierung und Hinzufügen/Löschen von Zeichen provozieren: eine Neuberechnung des Umbruchs im "labilen" Absatz kann den Fehler zur Erscheinung bringen oder ihn beseitigen.

Ist bei mir nicht nachvollziehbar, auch nicht nach mehrmaligen Versuchen und Text-Redraw.

Was schließen wir nun aus dem Ganzen ? Ein relativ sicherer Störenfried ist lokalisiert, alles andere unterliegt offenbar – mit unseren „Hausmittelchen“ - nicht näher erforschbaren Kriterien.

Ich denke Du liegst mit der CS4 doch auf der sicheren Seite der unsicheren Seite.

Viele Grüße Peter
•-------------------------------------------------------------------------------------------------------------------------------
iMac 27" Retina 5K, i7, macOS 13.6.6 Ventura, Acrobat Pro, Illustrator CC2023, CC2024, Affinity V2

Dieser Thread ist uralt - das diskutierte Problem in InDesign CS6 aber immer noch akut.
Mich würde interessieren, ob sich diesbezüglich in neueren CC-Versionen etwas getan hat.

Uwe (Laubender), ich spreche Dich hier offen und gezielt an, weil ich entsprechende Informationen am ehesten von Dir erhoffe. Weißt Du etwas von Verbesserungen im Kontext des WorldReady Composers in höheren CC-Versionen? Während meiner Recherchen im Adobe InDesign-Forum konnte ich keinen entsprechenden Hinweis finden.

Zum Hintergrund:

Antwort auf [ Peter Lenz ]

Ich denke Du liegst mit der CS4 doch auf der sicheren Seite der unsicheren Seite.

Die letzten 1,5 Jahre bin ich mit dem gemischtsprachigen Satz (englisch/deutsch/u.a. - hebräisch) von Büchern und Zeitschriften in InDesign CS4 gut gefahren: Ich kann mich an keine unerwünschten Spationierungen an zufälligen Stellen in CS4-Dokumenten erinnern.

Antwort auf [ Peter Lenz ]

Was schließen wir nun aus dem Ganzen?
Ein relativ sicherer Störenfried ist lokalisiert

Dieser Schluss blieb in der Konsequenz bzw. in der Praxis unbefriedigend:
Das Sonderzeichen "Bedingter Zeilenumbruch" mag den diskutierten Fehler tatsächlich an einzelnen Stellen begünstigen. Das Vermeiden dieses Sonderzeichens bedeutete aber keine Garantie, dass der Fehler ausbleibt. Dies habe ich soeben (in InDesign CS6) nochmals an Testdaten ohne das Sonderzeichen "Bedingter Zeilenumbruch" mit Erfolg provoziert.


Meine Anfrage wiederhole ich deswegen an dieser Stelle, weil ich mich durch den zwar erfolgreichen Einsatz von InDesign CS4 bei Satzarbeiten, die den WorldReady Coomposer erfordern, inzwischen anderweitig blockiert sehe: meiner Erinnerung nach soll InDesign CS4 unter MacOS 10.11 (El Capitan) nicht mehr zuverlässig laufen. Deswegen habe ich mein Betriebssystem auf MacOS 10.10 (Yosemite) quasi eingefroren. Es ist eine Frage der Zeit und eine Frage der Sicherheit (ausbleibende Sicherheitupdates für Yosemite), die mich zwingen, in absehbarer Zeit auf ein wenn nicht aktuelles (High Sierra), dann zumindest auf eine gestriges (statt eines vorgestrigem) Betriebssystem upzudaten.

Gerne würde ich InDesign CS4 durch InDesign CCxx ersetzen, wenn ich begründete Hoffnung haben könnte, dass dieser Fehler nun nicht mehr auftaucht.



Viele Grüße
Martin

Hallo Martin,
wir hatten uns ja bereits per Mail ausgetauscht. In CC 2018.1 hatte ich zumindest eine Besserung der Angelegenheit gesehen.

Folgender Bug-Report scheint das aber zu widerlegen, wobei Matthew Williams zum Zeitpunkt des Reports nur über die CC 2018 verfügen konnte:

World-Ready Composer Is messing up the kerning in Latin fonts
Matthew Williams | Jan 11, 2018

https://indesign.uservoice.com/...ng-up-the-kerning-in

Ich habe mal mein Votum für einen Bugfix abgegeben und einen Crosslink auf diesen Diskussionsfaden gepostet.
*****
Mit herzlichem Gruß,
Uwe Laubender

Mich wundert ohnehin, dass der Aufschrei aus dem Mittleren Osten nicht größer ist.
Denn seit CS6(!) ist kein sicheres Arbeiten mit dem WorldReady Composer mehr möglich.
Für diesen Zweck setze ich immer noch CS4 ein (CS5 und CS5.5 sind aus anderen Gründen [-> plötzlich leerer Textrahmen] für Mengensatz nicht zu gebrauchen).

Es ist aber auch gut möglich, dass das Problem nur den gemischtsprachigen Satz mit Wechsel der Schreibrichtung zwischen links-rechts und rechts-links betrifft.
Bei rein arabisch oder hebräisch gesetzten Texten könnte das Problem aus diesem Grund eventuell gar nicht in Erscheinung treten.

Dafür, dass Du das mir auf den Nägeln brennende Thema immer wieder an sensible Stellen heranträgst und Verknüpfungen zu unseren Erfahrungen und Diskussionen herstellst. bin ich Dir sehr dankbar.

Viele Grüße
Martin

Hallo Martin,
nun, dann soll mal jeder der hier reinschaut für den Bugfix voten :-)
*****
Mit herzlichem Gruß,
Uwe Laubender

Hallo zusammen,
ein Jahr später, der Bug scheint immer noch zuzuschlagen.

Hier ein aktuelles Beispiel im amerikanischen InDesign-Forum:

RTL + LTR lang in one paragraph with justification
annahayat Mar 17, 201
https://forums.adobe.com/thread/2605107

Auf InDesign Uservoice hat sich auch im letzten Jahr nicht sehr viel getan. Zur Zeit zähle ich nur 11 Votes, die für einen Bugfix stimmen:

World-Ready Composer Is messing up the kerning in Latin fonts
https://indesign.uservoice.com/...ng-up-the-kerning-in

Sinnigerweise ist der Report mit "NEED MORE INFO" gelabelt.

Ich kann also nur allen Betroffenen raten, sich im InDesign-Prerelease anzumelden, um den Bug dort zu diskutieren und mit entsprechenden Beispielen zu unterfüttern: Sreenshots, InDesign-Dateien und exportierten PDFs.
*****
Mit herzlichem Gruß,
Uwe Laubender

Hallo Uwe,

diese Beobachtung kann ich aus aktuellem Anlass (unter CC 2019) leider bestätigen.

Unter CC 2018 hatte ich den Eindruck, dass es besser sei. Möglicherweise habe ich aber auch nur nicht genau genug hingesehen.

Sicherheitshalber werde ich neue Bücher/Zeitschriften, in welchen Rechts-Links Schreibung nötig ist, weiterhin auf einem alten Rechner mit Yosemite in InDesign CS4 setzen. Eine tickende Zeitbombe.

Ist es möglich, dass das Problem nur bei gemischten Schreibrichtungen (links-rechts und rechts-links) auftaucht? Ansonsten müsste ja seit Jahren ein lauter Aufschrei aus dem Mittleren Osten erschallen.

Aus der Zeit, in der sich nicht Adobe, sondern winsoft.fr um den Globalen Absatzsetzer kümmerte (bis CS5), ist mir dieses Problem nicht erinnerlich.

Viele Grüße
Martin

Hallo Martin,
könnte unten zitierter Workaround funktionieren?

LinusCMH Mar 18, 2019 12:19 PM (in response to annahayat)
https://forums.adobe.com/...ge/10983724#10983724

Zitat von LinusCMH

I reported this same bug several years ago and have been reposting about it since. It first showed up for me in InDesign CS6. While I am still being frustrated by it, but I am cautiously hopeful that it will be resolved relatively soon. Adobe contacted me late last year requesting a file showing the issue, which I sent. It appears that they are finally at least working on it.

What I have found helpful as a runaround is to force InDesign to recompose all stories. You have to be careful, though, that once you've forced the recomposition, you don't do anything that will cause InDesign to recompose on its own. Simply scrolling or jumping to another page can re-corrupt affected paragraphs. To prevent this, I generally ignore the issue until I'm finished working on the file. I then navigate to the first page in the document, force the recomposition, then save the document and close it.

On a Mac, the keyboard shortcut to force InDesign to recompose all stories is Opt + Cmd + /.

*****
Mit herzlichem Gruß,
Uwe Laubender

Hallo Uwe,

Zitat von LinusCMH

What I have found helpful as a runaround is to force InDesign to recompose all stories.

Danke für diesen Hinweis.
Das Neuumbrechen aller Textabschnitte und direkt anschließender PDF-Export hat mir gerade kurz vor Drucklegung eines Buchs geholfen, diesen fiesen Fehler mit den willkürlichen Spationierungen zu lösen.

Ein erster Kontrolldurchgang stärkt die Hoffnung, das jetzt alles in Ordnung ist.

Die Fehler konnte ich dieses mal über einen Vergleich der (vorläufigen) Druck-PDF mit einer früheren (vom Autor abgesegneten) Version in Acrobat aufspüren.

Das Fiese ist eben dies: man darf sich nie in falscher Sicherheit wiegen. Auch in einem Dokument, in dem man den Fehler ausgemerzt glaubte und ihn nicht mehr nicht mehr beobachten konnte, kann er sich bei einer einfachen Änderung im Textabschnitt (Ergänzung, Ersatz oder Tilgung eines Zeichens) wieder einstellen.

------
edit: zu früh gefreut. Während der Fehler an den meisten alten Stellen behoben ist, taucht er jetzt an anderen Stellen auf.
Es ist zum Mäusemelken!

------
nochmal edit: mein Fehler war der: Man muss nach dem Neuumbrechen aller Textabschnitte das aktive Dokument sofort exportieren. So scheint es zu funktionieren.
Vorhin hatte ich das aktive Dokument neu umbrochen, gesichert und geschlossen und dann über die Buchfunktion exportiert. Möglicherweise schleicht sich der Fehler über das temporäre Öffnen während dem Buchexport bereits wieder ein.

Viele Grüße
Martin

Heute erreicht mich die Nachricht über die Behebung des Fehlers, den ich seit InDesign CS6 (v. 8.0) beobachte, in InDesign v. 15.0:

Zitat von Abhinav Kaushik

Hello All,

Thank you for reporting the issue to us.
We have fixed the issue in the latest version of InDesign, Id 15.0

Please upgrade your InDesign application to the latest version to try out the fix.

If you face any problems with the new update, do let us know in the comments.

-InDesign Team

https://indesign.uservoice.com/...be102c856bd8f8cce39c


Allerdings ist ID v. 15 m.W. noch nicht veröffentlicht.

Viele Grüße
Martin

Hallo Martin,
doch, InDesign CC 2020 ist seit ein paar Stunden öffentlich. Version 15.0.0.155.
Allerdings braucht's regional bedingt vielleicht einen Tag mehr, dass wir die in der CC Desktop App sehen.

Hier die Liste der Bug-Fixes:
https://helpx.adobe.com/...kb/fixed-issues.html
*****
Mit herzlichem Gruß,
Uwe Laubender