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.

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

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

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.

Hallo Jörn,

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

Viele Grüße Peter

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.

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

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 ...

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.

@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).

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

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.